网课学习笔记
捣鼓键盘的小麦-笔记
捣鼓键盘的小麦
合集·Web 杂谈
个人页面 https://space.bilibili.com/3349949
整体介绍的还可以
https://space.bilibili.com/3349949/lists/3295666?type=season
01 开源黑暗面-供应链投毒
面向开发者供应链的投毒:npm 类似的名称,直接集成到常用工具中(zip压缩软件),pipy 工具库等,或者合并到 linux 操作系统中,还不算硬件层面的投毒后门事件。
供应链:源代码——SDK——软件——客户,所以会影响开发者和客户群体。
案例:2024年4月npm上存在700个投毒的包(恶意组件),包括恶意文件下载或执行,代码混淆执行,释放恶意文件,执行 shell 脚本。
解决:
1、定期进行代码审计,小心选择第三方依赖,安全培训
2、建立强大的安全预警机制和响应机制

02 明水印和暗水印
明水印是视觉可见的水印,防君子不防小人。
暗水印是视觉不可见的水印。暗水印加密后,可以抗干扰(例如裁剪,缩放,遮挡部分内容),二次拍照,扫描通常可以解密。
暗水印算法:离散小波变换、最低有效位(LSB)将数据嵌入到图像的最低有效位,将加密信息写入图片的颜色深度位中,且对显示效果影响不大。


03 AI 能做到哪些网站
现在宣传AI可以做网站,3分钟完成一个网站,实际上效果怎么样?
AI 可以实现:
1、辅助编码(github copilot, marscode 等工具)
2、辅助设计:根据设计稿绘制HTML,编辑网页(UI 生成器 anaconda, durable, 及时设计)
因为软件工程阶段性强:需求分析阶段,比编码实现用时更多,AI 还不能支持复杂的需求分析阶段。
网站设计还包括:多网页架构组织,部署运维,数据存储,流量调度,网络安全,算法优化等
当前AI做网站:可以完成 demo 页面,一次性页面,个人简历。对中大型企业级别网站还不够。

AI 目前不能实现的部分:
1、需求覆盖不完善,需要不断调整提示词,可能达不到预期,需要大量上下文代码
2、事故责任划分
3、后期维护改动后,缺少长期记忆,容易改动已有功能,产生破坏性更新

04 CDN
CDN: 内容分发网络
传统的 CDN 只能缓存静态文件,例如图片媒体文件,目的是用户可以从最近的节点获取静态资源,速度更快。
现在的 CDN 功能比较多,还支持反向代理,函数计算,对象存储,边缘计算。下面结合个人的理解,简介这些功能。

反向代理:类似 nginx 反向代理功能,CDN 节点可以避免用户直接请求到源服务器,过滤非法请求,减少源服务器的压力。
对象存储:和传统的 mysql 关系型数据库对比,对象存储类似 sqlite 是键值对进行存储,适合静态资源的存储和缓存。源服务器和 CDN 节点上设置资源缓存时间。客户端请求 CDN 先走缓存,没有缓存或者缓存过期,再访问原服务器的资源。
CDN = 反向代理服务器(nginx) + 缓存(cache)

函数计算:是事件驱动的计算服务,写好函数代码上传就行,有对应触发事件时,函数就执行,按执行情况分配计算资源,处理业务逻辑。适用于 CDN 里复杂、动态、基于代码逻辑的业务处理,像生成个性化推荐内容、多媒体内容转码等。函数计算可以位于中心节点。
边缘计算:把计算任务放到靠近数据源或用户的边缘节点处理,在 CDN 里就是靠近用户的边缘服务器,能就近处理数据,减少延迟。聚焦利用边缘位置优势,优化网络性能、减延迟、减轻中心服务器负载。用于对响应速度要求高的场景,如在线游戏操作处理、视频直播内容优化等。边缘计算还用于图片防盗链,网页重定向,图片转换等。
05 ESR 边缘服务器渲染
这一节是上一节 CDN 的应用,就是把 deepseek 或者其他接口,部署在 CDN 上面的实践,属于边缘计算的扩展。
ESR:edge server render 边缘服务器渲染(SSR 服务器渲染的延伸,就是服务器去中心化后的实践)
就是在服务器上请求时,判断请求类型

直接初始化 openAI 需要申请 key token
然后把 AI 的返回值返回给客户端
相当于中间件拦截请求,并特殊处理

06 npm 版本号的含义
这一节探讨 npm 中不同版本符号的含义,简单的说就是安装第三方库的版本范围。

具体参考 npm 官方的说明
主要的版本规范如下:
稳定版本:固定的 a.b.c 分成大版本,中版本,小版本。大版本表示跨越式的升级,可能存在不兼容问题。中版本表示功能性升级,和上一个版本兼容。小版本通常是细节问题修复。
不稳定版本:带任意后缀(alpha, rc, beta 或者其他数字)只要是有 - 就是不稳定版本。
版本优先级:稳定版本按照数字对比。数字部分相同,那么稳定版本大于不稳定版本。

下面是具体的格式:包名:版本范围

安装依赖时,如果不指定版本号,默认安装最新的稳定版本,前面带一个 ^ 表示实际安装 1.x.x 的最新稳定版本。

^ 表示锁定主版本号

最新版本:必须是稳定版本,不稳定版本不是最新版本。如果不是刻意说明,不会安装不稳定版本。

特例:如果主版本号是0,^ 含义变化

^0.1.0 不能安装 0.2.0 版本,最高安装到 0.1.x,就是和 ~ 一样

总结如下

实际情况-根据不同依赖类型安装版本
1、react 锁定 x.y ,框架中等版本不同可能影响打包,所以是固定的版本,“react”: “18.3.1”,
2、axios 锁定 x,这种工具库更新很多,通常不会出现兼容性问题,使用最新的即可,“axios”: “^1.8.2”,
3、特殊库,指定 x.y.z,可能需要测试某个版本的功能,所以需要针对安装对应 xyz,“reactstrap”: “9.2.3”,
~ 锁定中间版本,实际使用不多
07 前端 + AI
谈 AI 对前端的影响:
-
AI 能否取代码农(前端,后端,测试?)
-
主力前端的核心竞争力是什么?
-
AI 能否抢走前端的核心竞争力?

AI的优点:
1、快速完成脏活累活(例如批量处理翻译,写文档写小说)
2、给出固定的需求,能快速给出答案(例如刷题,N皇后算法,滑动窗口算法)
3、给出需求绘图(创造性比较好,实际上效果还不满足)限定条件越多越好
局限性:
1、通用性问题很擅长(图片懒加载),专业性业务不一定擅长(例如资料库的具体数据结构优化)
2、复杂任务,上下文窗口有限。小项目充分的提示词,那么可以很好的完成。老项目代码很烂,上下文全部塞进去也可能效果不满意,因为已有代码不满足(例如给定代码中包含了 thumbnail 但是和缩略图无关,AI 还是会按照缩略图的需求写)
3、代码不一定满足复杂的产品需求(经常变化的需求),实际的需求并不是一句话就完成的。

前端核心竞争力?不仅仅是写代码,更重要的是对用户的洞察力,把用户的需求转换成需求文档。

AI 辅助编程的多个维度:
1、自动提示:输入前文可以直接提示——使用较多
2、辅助生成代码:根据需求写一个函数
3、直接完成功能:例如直接写出一个组件(辅助编程)
4、直接完成项目需求:初期分析需求,中期进行编码,后期自动测试上线(自动编程)
这里类似于自动驾驶和辅助驾驶。L1-L3 是辅助驾驶,L4是自动驾驶。
目前L1L2应用很多,L3正在尝试,实际上效果一般,还需要继续练习。


L4 只需要设置性能,覆盖率,稳定性指标,AI 可以直接完成全部工作。


作者建议:
1、真正理解用户体验,创造优秀的用户交互(如果是精品软件,没问题;如果是快餐式软件,没有必要。很多产品迭代很快,上面主要关注多久能上线,而不是说90% - 99% 的优化体验)

2、尽量多用AI(All in AI),类似搜索引擎,AI 大部分搜索出来的是正确的,但是及时性,可靠性,实际证明不一定合适。每一个AI的结果都有一个置信系数,AI 产品不会告诉你这个数字。所以,程序员需要有自己的判断能力。多用才能熟练使用。尽量多给出 AI 合适的提示词,才能让结果更满足需求。

3、AI first,优先使用 AI 考虑解决策略,解决各种任务。

AI as Tools 把AI当成工具,投入更多精力用于战略规划和团队效能上。

个人观点:
1、尽量多用AI,熟能生巧;多学习提示词怎么写,给定足够的条件,AI 才能完成更精确任务;一定要多写多写。
2、AI 能取代的任务,就避免做(例如翻译);优先做 AI 取代不了的活。
08 AI + 前端未来
这一节是前一节的扩展,AI 未来在哪里?AI 辅助研发、生成式 UI、下一代工程技术
AI 辅助研发
辅助研发,和上一节的类似,就是根据需求,编写代码

具体的 AI 工具 RAG SFT 可以基于自己的项目,进行调整学习。目前项目还没有做到这部分(上下文比较少,文档比较少)。

辅助研发,需要规定具体细节:例如风格偏好(代码格式),技术栈(第三方库)
这个规范可以做,自己做出来一份前端代码规范指南,以及后面的注释,业务组件示例等,这样AI命中率就会更高

RAG 目前还不支持,都是使用的公开的模型,不是自己训练的模型。这里核心是有自己的知识库,并且从知识库提炼出内容,和已有开源库 embeding 后,逐步训练自己的模型,这样才是符合自己要求的模型,不是公开的没有训练的模型。

模型是不断训练出来的,并不是直接上手能用。
不同模型应该分类规范使用,使用对应的智能体(例如前端,后端,生活,创建不同的智能体,处理不同的问题)

IDE + AI

生成式 UI
主要是创造性的方向,例如文档撰写,创作图片。

下一代工程技术
工具链一体化,工程实践 AI 化

目前前端工具很多很杂,例如下面的包管理,测试,构建工具。不同的工具细节不同,这就是AI还不完善的地方。

例如国外 React 构建的 Vite 体系

字节跳动全方位的工程技术栈

AI测试,直接使用AI模拟人员操作(更符合实际使用情况),而不是还在一行一行写单元测试。



09 前端请求发展历史
前端请求发展历史:
1、早期 form + PHP 发送表单:简单数据,前段后端代码混合
2、XHR 原生 JS 发送请求:实现了前后端的分离
3、Ajax 发送请求:避免了 XHR 复杂语法,简化请求对象

4、Promise axios
5、ES6 fetch:JS 出现标准化 fetch,避免了 axios 等第三方库的封装(语法类似 axios)

6、ES8 async await: 避免回调地狱,实现线型处理(此时的 catch 可能是中间的某一步,或者是 JS 错误,直接捕获明确哪个请求出错比较难)。目前网络条件越来越好,出错的情况是少数。

10 浏览器渲染变迁
这一节不分析浏览器内部渲染的逻辑(CSS tree, render Tree 等),主要分析渲染网页变化的过程,以及背后的原因。
早期是服务端模板渲染(django 模板)中期是客户端渲染(React 前端渲染)现在趋势是服务端渲染首屏(性能高),客户端渲染其他页面

客户端渲染的优缺点

服务端渲染的特点:客户端和服务端可以使用同一份 HTML,客户端添加 JS 做交互(水合)

具体的代码层面,就是客户端和服务端使用同一份 APP 组件

服务端渲染的变体(SSG,静态站点生成,主要是固定的页面)

具体的框架就是 Huge,Hexo 等

增量静态再生


流式渲染


React 服务器组件



11 不破不立的前端三十年
https://space.bilibili.com/3349949/lists/3295666?type=season
作者还在不断更新中
合集-现代前端开发必知
个人页面 https://space.bilibili.com/3349949
大厂前端
整体介绍的还可以,其他的专辑也可以看看
https://space.bilibili.com/3349949/lists/3439209?type=season
01 如何成为现代前端六边形战士
作者提出,现在前端的工作不仅仅是传统前端的知识体系,涉及服务器开发,工程部署方面。
这个系列会简单介绍前端新发展方向,以及为什么这样发展。
这个系列只是一个科普,不会具体谈一个工具的细节,具体还需要自己实践应用。
为什么要成为六边形战士?因为技术不断发展,竞争很强,前端和后端没有明确的界限,懂得多才能留下
前端新概念
构建工具:webpack Vite turbopack Rspack(rust重构后速度更快) Pnpm webassembly 服务器组件
框架:NextJs 和 React 的区别,Nuxt 和VUE
概念:CSP 可观测性 边缘计算 灰度发布 WAF Serverless
现代前端 = 用户体验(网页性能、无障碍、交互设计、个性化需求、多端适配) + 工程化(研发提效、前端安全、监控和数据、部署运维、数据运营、终端安全)
渲染流程:客户端渲染(传统 HTML 解析过程,获取资源,渲染信息,获取字段,渲染信息)——服务器渲染——流式渲染(Nextjs,发送多个请求,按照流水线渲染页面,速度更快)
边缘计算:满足偏远地区用户打开网页速度问题,解决云服务器成本较高的问题,cloudlare 提供服务
前端新知识体系
这里只介绍新内容,已有体系不重复,对应后面几节课程。
-
计算机网络:DNS HTTPS websocket
-
编程语言:ecma 运行时,标准库
-
UI
-
应用框架:react, vue, 小程序,桌面,移动原生
-
服务端
-
工具链:AI、IDE,包管理,构建工具,调试工具
-
质量保证 QA:防御性编程,代码审查,质量工程,测试
-
用户体验:无障碍,个性化
-
CICD:持续集成,持续部署,工具
-
可观测性:日志、追踪,度量
-
云基础设施:网络、容器、存储、安全、Saas
02 上期回顾 & 章节概览
大厂中,也并不是一个人精通所有东西,各有所长
这个视频主要是开阔眼界,方向性指引,不是具体技术细节。这个不涉及计算机基础,主要是前沿技术和实际应用。
个人觉得发展就像木桶,不能有短板,必须有长处。
前端各种工具各种框架很多,我们不需要也不可能每一种都精通,知道其差别,然后熟悉某一个技术栈
不同规模的产品,需要不同的技术栈
-
小型:create-react-app,flask
-
中型: plugins, django
-
大型:SSR CICD
03 计算机网络
DNS 域名解析、缓存控制,实际的流程:
域名解析流程:应用程序——本地host——本地DNS服务器——根服务器——顶级服务器——权威服务器
小型项目(单机网站,1台后端服务器),域名和IP是一一对应的关系,可以理解成IP直接访问服务器。
大型项目中,域名和网络运营商是一对多关系,对应不同地点,不同 IP 也是多对多关系,然后再访问负载均衡服务器等。多以 DNS 是动态解析。根域名可以对应一个 IP,子域名可以对应另一个 IP(CNAME)。造成了第一次访问网站时,实际需要很多次的域名解析,耗时较多;后续访问网页时耗时减少。

现代DNS 其他功能:安全插件,DDoS防护,边缘网络极速,DNS分析。
因为 DNS 存在多次访问,所以可以进行 DNS 优化:
-
更换高性能 DNS 服务器
-
DNS 缓存
-
增加 TTL (缓存时间)
04 你需要知道的 HTTP 协议
HTTP:超文本传输协议,不仅仅传送文本,还支持传输多媒体
版本
-
HTTP 1.1 广泛使用
-
HTTP 2 多路复用;二进制帧层;头部压缩
-
HTTP 3 QUIC 协议,使用 UDP 协议
不是所有的都支持 HTTP23,所以可能存在很多问题。
关注服务器返回码,明确主要的含义(200, 300, 400, 500)
关注请求头和响应头,主要字段的含义

content-type 内容类型
下面主要介绍 content-type 内容类型,这个在客户端和服务器通信很重要
例如下面的例子
-
客户端发出的请求类型 content-type : JSON 格式,那么就需要把对象转化成 json,服务器就需要使用 JSON.parse() 进行解析数据(深蓝色部分)。
-
服务器返回的数据类型是 content-type: text/plain 格式,那么客户端直接从 res.text() 进行解析即可。
通常不一定规定具体格式,只要前后端数据类型一致即可。所以如果一个人同时写前后端代码,就可以避免这些问题,如果是其他人写服务器的代码,还需要具体看内容类型,发送的类型,就很费时间。
前端默认的类型是 json,后端默认的类型是 form 表单,这样就造成了前后端数据接收不到的问题。

其他字段也很重要,根据需要不断学习补充
调试方法
1、浏览器的 devTools,全面具体
2、终端的 curl 命令,快捷
3、批量测试,POSTMAN
4、移动设备调试:抓包工具,安装信任证书和网络代理工具
5、服务器调试:抓包,分析日志
大型网站的 GateWay 网关
登录验证,请求监控,限流,分析
客户端可以对 HTTP 协议进行定制 gRPC
例如请求 bilibili.com,类型就是 grpc 请求到 gateway 站点,然后进行转发(可以携带更多客户端的信息)
05 编程语言、ES 标准、JS 引擎、运行时
编程语言:
-
JS
-
TS:类型验证
-
Rust:打包构建速度快
-
其他特定场合的 wxml wss:专用于微信小程序,JSX
-
webassembly: 其他语言可以打包
JS 引擎和运行时:JS 在什么环境中运行?浏览器,node环境,还是其他特殊环境?
通过分析运行环境,选择最后的打包产物。
06 前端工具链
工具链(前端工程化)
包管理:npm(使用多,兼容好,速度慢,容易污染) yarn(并行安装,本地缓存较多) pnpm(共享依赖,兼容性比较多)
多包管理:monorepo,workspace larna rust
构建工具:gulp webpack rollup rspack vite
-
转译器:babel 把 es6 转换成 es5
-
优化器:压缩,混淆,分割
-
打包器:bundle
-
开发服务器:dev-server,HMR 接口代理
-
各种插件
调试工具:
-
浏览器 devTools
-
小程序开发工具
-
特定框架调试工具 React 组件调试
CI-CD
-
github actions
-
Travis CI
07 解锁构建用户界面 UI 框架
CSS框架:bootstrap
UI 框架:React
组件库:ant-design
这部分日常使用很多
08 前端应用框架
现在市场上很多前端应用框架,他们相对于 react VUE 等框架,有什么区别?
react:是一个用于构建用户界面的框架(UI 框架),专注于组件化开发和状态管理。它本身是无服务器的,需要配合其他工具(如 Webpack、Babel)才能构建完整应用。
Next.js:是基于 React 的全栈框架,扩展了 React 的功能,提供了开箱即用的服务器端渲染(SSR)、静态站点生成(SSG)、路由系统等,属于 “React 生态系统的上层建筑”。

简单点,就是 应用框架集成了 路由,样式UI,数据获取,测试,插件,部署等一个或者多个功能。
例如 TARO 可以把代码编译成不同类型的小程序,这就算应用框架。
多页应用 MPA:传统的技术,django 不同的路由对应不同的 HTML,切换不同页面,需要重新请求服务器的 HTML,重新进行渲染。
单页应用 SPA:切换不同页面不需要全部渲染,多页切换过程比较流畅,但是首屏加载时间较多。
渐进式网页应用 PWA:类似小程序的架构形式。
可以看到,不同应用框架支持的技术不同,选择合适的开发框架可以减少开发负担。

09 性能优化方案
性能优化方案,这个可以讲的东西有很多,例如网页性能,用户体验,个性化设置等。这个分成不同小节分开介绍。
性能分析工具,通常浏览器自带开发工具就可以了,其他的工具实际使用再说。

避免过早或者过度优化性能,应该首先关注产品实现。目前的项目中,优先实现产品功能,如果用户反馈严重卡顿等问题,然后再考虑性能优化的问题。
1、可以根据浏览器-performance-渲染时间线,红色部分就是阻塞部分,通常是 JS 执行阻塞了浏览器渲染。
2、根据渲染时间,确认 FCP,首次渲染时间,可以计算白屏时间。
3、页面加载时间过长(资源体积大,网络延迟高,没有设置合理的缓存,渲染受阻)
4、交互过程不流畅
5、资源消耗过度
具体每一个点都能讲的很深。
-
资源体积大解决方案:压缩代码,tree-shaking,依赖外置(lib单独打包)、代码拆分、按需加载、服务端渲染、服务器组件、流式组件等等。
-
网络延迟较高:HTTP2 多路复用,二进制帧层,头部压缩,提高网络的并发传输效率。
-
浏览器资源提示:preload, prefetch, dns-prefetch, pre-connect
-
图片优化:webp avif 格式压缩空间
-
缓存:本地浏览器缓存(http 缓存头,cache-control, last-modified, etag 协商缓存存储方式, web storage),服务器缓存 (内存缓存,边缘缓存,网关缓存)
-
渲染受阻(async defer 渲染脚本受阻,web workde 用于计算高的部分,避免阻塞渲染进程,web-assembly)
-
交互过程:数据量大(长列表,虚拟列表,分页加载),用户点击频繁(debounce 防抖, throttle 节流, useTransition useDeferedValue),动画效果过多(抢红包动画点击效果),统计图表性能(大数据抽稀,主成分提取,分片渲染,canvas 加速, webGL 加速)

动画效果过多:开启css硬件加速,transform opacity perspective 或者专业的动画框架 lottie, react-motion
资源消耗过度:占用大量的 CPU 或者硬件资源,克制使用第三方依赖
容器技术(淘宝小程序,微信小程序,支付宝小程序等)

10 用户体验
从 UI 设计,可访问性,个性化方面,提升用户体验
UI 设计-不同设备
加载反馈:用户打开页面(渲染骨架屏,避免用户白屏期间等待的焦虑感,主要是小程序和APP,可能存在网络条件不好的情况),执行操作得到的反馈(通常是耗时较长的操作,例如下单支付,前端应该展示全局或者局部的按钮 loading,避免用户产生疑问或者重复操作)
强弱依赖:用户打开 SPA 时,通常需要很多请求,可能存在 promise.all 加载全部内容后,才渲染界面。这样做不太友好。应该分清主要功能和次要功能,主要功能加载好就渲染页面(例如商品详情),次要功能加载失败不会影响主要功能的显示(例如评论)。
异常反馈:网络错误,可以以轻提示(toaster),强提示(alert)告知用户
兜底反馈:空提示,404访问提示
响应式设计:移动端响应屏幕尺寸的设计,保证在不同屏幕尺寸下可以得到良好的显示效果。
使用css媒体查询可以检测屏幕宽度高度,屏幕分辨率,色彩深度,是否触摸屏等很多条件,也是实现黑暗模式的处理方案。
|
|
媒体查询的局限性:只能影响 css 样式,无法改动 js 的交互逻辑。此时可以通过 JS 获取屏幕尺寸,判断设备,执行 JS
|
|
交互习惯适应:
1、加载更多效果:移动端使用滚动加载更多,PC 端通常显示分页器,显示具体多少页,加载了多少页等
2、菜单效果:手机上是下方的 ActionSheet,PC 上是 Dropdown 下拉菜单
3、按钮位置:手机通常下面一排按钮,PC 通常右下角一排按钮
可访问性-不同用户
主要是国际化业务(多语言方案),残障人士(屏幕阅读器,色彩对比度等),新手(新手引导)
个性化
主题,记忆,AB测试
主题:让用户切换主题色,让用户自定义背景图等
记忆:浏览器本地存储用户习惯的状态(侧边栏是否打开,筛选条件,页面滚动位置,大型表单预先填写)
AB测试:根据不同用户的喜好,UI 层面展示不同的效果(例如男性女性,VIP 客户和普通客户,显示不同的页面效果)
11 服务端技术栈
这里考虑和前端相关的服务端知识:
早期传统JS都在前端实现,现在前端功能越来越多(需要渲染),那么客户等待时间就增加;前端需要发送很多请求到后端,那么用户等待时间也会增加,所以部分功能需要在服务端实现(服务端渲染,聚合接口,安全策略,持久化日志)。
运行时 runtime
nodejs:最基础,最稳定的运行时,提供了文件管理,网络管理等
deno
Bun
基础框架
基于运行时封装的基础框架,减少了直接操作 API 的繁琐,专门为了构建 web 服务(5期视频)
express:app = express() 路由,http
koa
应用框架(APP framework)
在基础框架上进一步封装
nestjs: 进一步抽象了模块,控制器,服务的功能,验证,缓存,队列,日志,session 模块等功能,支持复杂业务场景
nextjs: 全栈框架
eggjs
sailsjs
krakenjs
应用架构(architecture)
MVC:model view control
restful
BFF: backend for frontend,处理大型C端业务,把不同设备来源的 API 进行整合后,统一发送到后端服务器(类似gateway的场景)

12 质量和安全
编码质量
三个常用方法:防御性编程,代码质量工具,代码评审等方法可以确保代码质量。
防御性编程:主要用于弱类型的语言(判空处理,判断类型,异常处理)
代码质量工具:静态检查工具 eslint,代码风格控制工具 prettier
代码评审:交叉验证代码的功能(代码架构是否合理,这些其他工具无法检测)
测试
单元测试,集成测试,兼容性测试(特性探针,埋点检测,日志上报)caniuse 等库,性能测试,UI 自动测试
攻击防御
xss:对用户输入进行过滤,sanitizeHTML 库可以进行过滤
csrf:同源检查,Token 检查
稳定性
供应链安全(package-lock.json) 提供安全的版本锁定,及时更新问题
应急预案(服务器存在延迟,给用户发送全局黄条提示信息 notice bar)

13 持续集成和部署
代码持续集成和自动部署 CI-CD
传统项目的局限
传统的简单个人项目:本地源代码——手动打包——上传到服务器——测试正常——用户使用
如果项目比较大,这样比较耗费时间。不同人本地环境不一样,可能打包结果不一样。所以要改成自动部署和持续集成。
CI 代码持续集成
githubAction,可以编写具体的规则和过程,使用 git 自动检测拉取代码,在容器中进行编译集成测试工作

单元测试覆盖率可以使用 codecov,增加测试报告。注意:截图中这个配置比较早,不正确,实际需要参考最新的文档。

CD 持续部署
把 CI 编译后的结果,直接自动部署到服务器上(流水线作业),控制发布流程;环境隔离 dev master
14 云基础设施加速前端开发
应用发布后,需要关注哪些问题?
云服务商给我们提供了很多云服务(不同的服务侧重不同的功能)
网络服务
cdn,域名,SSL证书等,DNS 域名解析
计算服务
云计算 serverless


早期服务器提供接口,客户端使用 axios 调用接口。serverless 提供 SDK,直接调用服务器的函数(方法),所以部署的服务器就是计算功能。

存储服务
oss 多媒体存储,多媒体压缩处理(例如制作图片的缩略图)
安全服务
https 防止黑客爬虫,隐私泄露

15 可观测性
网站上线后,需要做什么?
分析接口调用情况,分析异常情况,促进用户转化。
可观测性,就是通过日志追踪度量角度
前端监控(异常行为记录)+前端埋点(记录用户行为)
Sentry 可以提供前端监控功能,监听 window.onError 事件并把相关信息记录
16 总结篇 | 我心目中的前端大厦
总结:
本课程短小,主要是介绍性,具体知识还需要自己下去多看
-
基础篇(3-7节)计算机网络,编程语言,前端工具,UI 页面
-
进阶(8-12节)服务端,用户体验,应用框架,前端质量和安全
-
工业化(13-17节)CICD 云服务,上线后观测性
合集·通俗易懂 AI 应用开发
https://space.bilibili.com/3349949/lists/6061232?type=season
本课程对应的 github 仓库:https://github.com/micooz/ai-app-examples
1 介绍篇 | 前端通俗易懂的的 AI 应用开发
1、AI 应用、传统应用、自动化应用的区别。
自动化应用:类似工作流等固定流程,脚本自动化运行的应用。
AI 应用:利用 AI 技术构建的软件,软件具有智能化功能(分析——推理——行动)。
2、AI 应用涉及的技术栈。

基础层:大模型的训练,数据采集,训练算法(一般开发者不涉及,都是大公司进行研发)
接入层:MaaS 接入 AI 厂商的 API,或者利用自行运行服务(运行大模型,或者进行 RAG)
技术基建:
-
开发框架:Langchain LangGraph OPEN-AI-SDK
-
提示词工程:专门的 Prompt Engineering
-
RAG: 搜索增强生成,将本地的知识库加入到大模型中,或者进行蒸馏,获取特定场景的模型应用
3、本课程涉及的技术栈

具体前端技术点:React + Nodejs + Tailwind css + Shaden 组件库
2 实战篇 | 100 行代码实现AI聊天机器人
产品需求:创建一个终端的入门应用,可以调用大模型,进行一对一的教育问答。功能简单。

全部代码:https://github.com/micooz/ai-app-examples/blob/main/01-chatbot-cli/main.ts
github 上面代码和实际视频的代码有调整。github 代码为了体验,直接放在一个文件中,减少了不必要的配置。
核心代码:一个永久循环,用户输入,AI 回复,页面上显示内容。把消息记录放在 messages 数组中,每次输入都把全部上下文发给 AI 大模型。
消息类型分成:user agent system 三种类型,只支持字符串进行输入输出
主要代码和解析如下:
|
|
启动服务时,需要补充环境变量,或者安装 dotenv 第三方库自动获取环境变量
|
|
3 解析篇 | 模型、提示词、上下文
解释上一届中 AI 应用中的关键概念:模型 model、提示词 prompt、上下文 context
关键参数
-
API-key 进行鉴权,不同项目的额度管理
-
Base url:不同的 URL 进行不同的作用,例如后面加 chat embedding files 分别用来处理聊天,嵌入,文件管理
-
model:模型的名称(plus max)
这三个关键参数是每一个大模型必须的,切换不同大模型时,也需要考虑更换这几个参数,具体看官方最新的文档。
API 返回值
API 返回了大模型的输出结果,通常还返回了模型的 tokens 使用量,前端可以根据使用的情况,调整合适的上下文长度等。
prompt_tokens, completion_token total_token 等不同的用量。
提示词
提示词是输入到模型中的指令,包括是用户的请求或者系统预设。这里有单独的提示词工程,有专门的课程。
上下文
上下文工程,就是 messages 数组,这是模型调用中很重要的部分(选择多少上下文,什么时候需要做取舍)
[system, user, assistant, user, assistant] 还包括调用不同的 agent 等工具
具体还有上下文持久化,上下文窗口限制,模型注意力,多窗口信息共享等细节。
——————————
这个课程是基本的引导,具体某个领域研究,还需要深入研究。
4 JS 中的流式处理技术 Iterator、Generator、for await…of
问题提出
上面给到的案例中,通过 API 进行一问一答形式进行交互。如果回答内容很多,那么需要用户一直等待回复,体验不好。
这里可以进一步,优化成流回答模式(API 以 Stream 形式返回,然后前端以流模式一个一个字动态展示返回的内容)。
需要用到下面几个前端高级语法进行实现:
流式输出案例
在请求时,增加 body 字段 { stream: true } 表示需要流式输出
此时服务器就是以流模式返回的结果,可以看出 content 是一个一个文字进行返回的
客户端 JS 解析步骤如下:
1、先把 response 这个流式返回值,使用 for await (const value of response) 进行异步循环。
2、使用 text-decoder 进行解码,就是把流式的 Unint8Array 转换成字符串进行处理。
3、使用 split 进行换行,使用 map 去掉空格,使用 filter 去掉空行。
4、循环每一行内容,判断如果是 DONE 表示已经结束。
5、将每一行的字符串,去掉开头的 data: 部分,然后 JSON.parse 转换成对象,进一步获取 content,拿到内容。
6、将 chunk 打印到屏幕上,并循环写入到回复 reply 中,最终将 reply 写入到 messages 中。

流式循环 JS 分析
上面代码中 for await (const value of response) 是流式循环,这个是 JS 代码的核心。
在 es6 中引入了迭代器,使用 for of 可以对迭代器进行循环。for of 实际上就是一个语法糖,默认迭代器的第一个值 node,然后 node.next() 获取下一个,直到获得不到下一个,实际上就是按照链表来遍历数组。数组就是一种特殊的迭代器。
在 es9 中,引入了异步迭代语法。可以对 fetch 到的异步结果进行迭代。

此时服务器返回的是一个流模式,前端也可以模拟异步返回流。
例如新建一个生成器函数 function* gen() { yield 1; yield 2; } 进行流式返回,这个函数需要不断 .next() 获取下一个数字。
此时可以使用 for of 来解析流,这就是用 js 生成器函数模拟的效果。

5 图解 SSE 协议的前后端实现
在上一节课程中,了解如何流式接受信息,那么已有的很多通用大模型交互方式,是服务器多次向客户端发送消息,已经有很多框架封装实现了相关的技术,不需要手动去处理细节部分。
SSE: server sent event 服务器发送事件
LangChain 调用模型接口
langchain 封装了很多有用的方法,这里是调用 core 核心方法,减少客户端自定义数据结构。
langchain 封装了不同类型的 message,以及封装了 model.stream 流处理方法,客户端直接能获取到 chunks。

Express 实现 SSE
服务器处理 SSE 比较容易,直接在响应头中增加内容类型是 event-stream ,然后就可以先给客户端返回响应头,然后按照 for await 接受到大模型返回的 stream 数据,再返回给客户端。返回结束后,调用 res.end() 结束。

客户端使用 EventSource GET 请求接口
默认可以使用 EventSource 内置的对象进行请求,这是 GET 请求,请求长度有限制,且不能携带 token 等验证字段。
然后通过不同的事件处理函数,接收消息。

客户端使用 fetch POST 请求接口
因为上面 GET 请求有局限性,所以这里可以使用 fecth POST 进行请求,然后在 then 中处理流式的结果。

6 智能应用的两种开发范式 Workflow 与 Agentic
智能应用的核心——语义匹配
Workflow 模式
工作流模式通常是一条固定的流程,需要维护大量的判断节点。
|
|
Agentic 模式
动态流程+多轮推理,根据上下文自主决策下一步操作。
Re-Act: Reasoning and Acting 迭代操作。
模型会循环调用工具,并回顾调用结果,决定继续调用还是返回,给了模型很大的自由度。
这两个模式适合不同的使用场景。