星光の平

Agent记忆到底应该怎么实现? 一篇文章带你读懂记忆实现 !

Fri, 05 Jun 2026 13:00:00 GMT

`Agent为什么需要记忆?`

LLM(大语言模型) 是 Agent 的大脑, 它是一个非常聪明的天才, 但是它没有记忆, 你问了它上一句, 回复之后都忘掉了, 鱼的记忆有 7 秒, 但是大语言模型的记忆只有 0.0001 秒…… 关键概念 :

无状态: 你给它一段输入, 它算下段输出, 算完就忘
上下文窗口: 如果你想让你的模型带有记忆, 你可以给它加上下文窗口(就是加载之前的记忆), 但是模型最多一次只能看固定的上下文长度, 它是按照 token 来计算的, 如果 token 过长之前的内容会被挤出去, 部分失忆, 所以我们需要记忆 !

Agent 记忆四层架构

存储结构

向量存储：用于相似性检索的记忆表示
分层结构：按时间或重要性组织的记忆层次
图存储：记忆间关联关系的图结构表示
记忆模式：不同类型记忆的存储范式

写入机制

触发时机：记忆写入的触发条件与时机
信息提取：从交互中提取关键信息
写入决策：决定哪些信息需要持久化存储
链接生成：建立记忆间的关联关系

记忆管理

遗忘机制：主动或被动遗忘不重要记忆
合并压缩：相似记忆的合并与信息压缩
记忆演化：记忆随时间的更新与演变

读取机制

检索测试：检索系统的评估与测试
检索增强：提升检索准确性的技术
排序与返回：检索结果的排序与返回策略

三种位置记忆

上下文记忆

存在当前输入窗口里面, 上下文记忆是临时的, 不可跨会话进行读取, 并且窗口大小是有限的, 每一次的对话都是一个更新

外部记忆

主要是体现在当前的这个数据库里(或向量数据库), 容量是无限的, 可以跨会话回答, 修改非常灵活, 可以直接操作并且执行 CRUD, 外部记忆通常是通过检索然后拼接到上下文当中的, 主要用来存储用户的画像和一些长期事实

外部记忆的四种主流形态:

检索式记忆: 将每条记忆做 embedding 存进向量库, 需要时按语义相似度检索 top-k 拼进上下文, 本质就是把 RAG 用在对话历史或者用户画像上
结构化记忆: 将记忆组织成键值对, 表, 图谱等结构, 适合精确, 可更新, 需要推理的关系场景中
摘要式记忆: 将有限的上下文记忆当内存, 将外部记忆存储当硬盘, 当会话变长的时候, 旧内容滚动摘要压缩成要点存档, 需要时再翻页召回, 这就是 MemGPT 的核心直觉
笔记式记忆: 让 agent 把重要的结论写入文件, 下次任务开始先读这份笔记, 这是编码式 agent 非常实用的方法

参数记忆

参数记忆一般是通过训练或微调实现来的, 成本比较贵, 但是参数记忆加载非常快, 容量由参数数量来决定, 相对固定

外部记忆的四个策略

write: 写什么, 何时写?

不是所有的对话都需要记忆, 只需要在对话当中抽取稳定的事实, 偏好 ,结论等, 给每条记忆重要性打分, 可以在会话结束的时候触发写入, 或者触发式(检测到某一段文字)来写入

read: 怎么找回?

检索记忆不能只看语义像不像, 而是靠三部分的因素去打分

相关性
新近度(他有多新, 多近被使用过)
重要性

update: 信息变了如何更新?

当新信息和旧的信息冲突时, 不能两个都存在, 需要进行修改, 然 llm 来判断应该如何处理(crud) 四种更新优化机制:

全量数据更新（当新信息与记忆库中的相似度小于 0.7 时，进行增量式更新）
更新现有记忆（相似度大于 0.8 时，更新记忆内容）
删除过时记忆（当记忆的重要性系数低于阈值时，自动删除）
不执行任何操作（信息已存在且完全相同时，可触发复习机制，提高该记忆的重要性权重）

forget: 为什么要主动忘记?

长期没有被命中的需要主动删除衰减, 不然数据库会越来越脏, 检索越来越差

做好离线整理

人不能把每件事情都塞进长期记忆, 如果内存中只添加不整理, 会越来越乱

反思 Reflection : 用 LLM 把一批零散观察提炼成高层洞见并存回记忆 睡眠时计算（「梦境」）: 空闲时主动把上下文预先嚼碎（预摘要 / 预生成可能被问的 QA / 预整理） 后台自我评审 : 后台用 critic / verifier / 自动回归持续自查自纠

AI Agent 的新战场：从会动手，到被允许动手

Tue, 19 May 2026 13:00:00 GMT

小龙虾证明了 AI 可以动手, 但 2026 年 6 月真正新的变化是：大厂开始把这种“动手能力”塞进真实业务入口，并同时补上治理系统。

三个最新信号：

Meta Business Agent：2026-06-03 全球推出，把 AI Agent 放进 WhatsApp、Instagram、Messenger 这些商业对话入口。Meta 官方称已有超过 100 万商家使用，三大平台每天有超过 10 亿条 business threads。它能回答问题、推荐商品、预约、筛选销售线索、关闭销售。
OpenAI Codex 扩出编程圈：2026-06-02 OpenAI 称 Codex 已有超过 500 万周活用户，知识工作者占 20%，正在用于报告、表格、合同、研究、数据分析和工作流自动化。
Microsoft Build 2026 推 Agent 控制层：同样在 2026-06-02，微软发布/强化 Agent 365、ASSERT、Agent Control Specification、Foundry observability，核心不是“再造一个 Agent”，而是让企业能控制、审计、评估 Agent。

AI Agent 的竞争正在从“能力演示”进入“入口占领 + 运行时治理”。谁掌握用户每天工作的入口，谁掌握 Agent 的控制平面，谁就可能掌握下一代软件分发权。

AI Agent 的新战场：从“会动手”到“被允许动手”

2026 年上半年，AI Agent 已经不是新鲜词。

小龙虾 OpenClaw 爆火、Manus 类产品走红、Codex/Claude Code 进入开发流，大家都已经知道 AI 不再只是聊天框，而是可以接工具、跑任务、改文件、操作浏览器。

2026 年 6 月真正的新变化是：Agent 正在从个人玩具和开发者工具，进入商业入口、知识工作流和企业控制系统。

换句话说，行业正在从第一个问题进入第二个问题。

第一个问题是：Agent 能不能做事？
第二个问题是：Agent 在哪里做事、替谁做事、谁允许它做、出了问题谁负责？

一、小龙虾不是终点，只是证明题

OpenClaw 的意义很大，它完成的是一个证明题：AI 可以从聊天框里出来，变成本地电脑上的执行代理。它能接通信渠道、文件系统、浏览器、命令行、插件、skills，用户可以像安排助理一样安排它执行任务。

这当然重要。没有小龙虾，很多人不会直观理解 Agent 的“手脚”是什么。

但到现在，问题已经在逐渐变化了。

小龙虾证明了 Agent 能动手；现在大厂在争的是，谁能让 Agent 在真实商业场景里规模化动手。

这就是 Meta、OpenAI、Microsoft 最近几天的动作为什么值得放在一起看。

二、Meta 的信号：Agent 正在进入商业对话入口

2026 年 6 月 3 日，Meta 发布 Meta Business Agent，并把它推向 WhatsApp、Messenger、Instagram。

这件事表面上看是客服机器人升级，实际更重要。

因为 WhatsApp、Instagram、Messenger 不是普通应用，它们是大量商家每天和客户沟通的入口。Meta 官方说，已经有超过 100 万商家在 WhatsApp 和 Messenger 使用 Meta Business Agent，WhatsApp、Messenger、Instagram 每天有超过 10 亿条 business threads。

Meta Business Agent 能做什么？

回答和企业相关的问题；
根据商品目录推荐产品；
预约服务；
筛选潜在销售线索；
决定何时转人工；
关闭销售；
未来连接 Shopify、Zendesk、Shopee 等系统，替企业执行更多动作。

这不是“AI 聊天”。这是把 Agent 放进交易前线。

过去，企业软件的入口可能是 CRM、官网、App、客服系统。现在 Meta 想让 WhatsApp/Instagram/Messenger 变成小商家的业务操作层：客户咨询、商品推荐、预约、销售、复盘，都在对话里发生。

这比小龙虾更值得写，因为它说明 Agent 不再只是极客给自己装的本地助理，而是开始进入真实商业分发渠道。

三、OpenAI 的信号：Codex 正在从“写代码”变成“知识工作后台”

同一天，2026 年 6 月 2 日，OpenAI 发布 Codex 使用报告，称 Codex 已有超过 500 万周活用户，是 2 月桌面应用推出以来的 6 倍以上。

更关键的是：OpenAI 说开发者仍是最大用户群，但知识工作者已经占 20%，且增长速度超过开发者的三倍。

这些知识工作者在用 Codex 做什么？

生成报告；
做表格和数据分析；
写合同和文档；
做研究；
自动化工作流；
搭轻量工具；
并行运行多个任务。

这说明 Codex 不再只是“程序员写代码更快”的工具，而在变成一种通用知识工作执行环境。

这一点非常关键。

过去知识工作者的瓶颈是：想法在脑子里，执行卡在工具里。要做一个分析，需要找数据、写公式、做图、写报告、发给别人改。要自动化一个流程，需要找工程师写脚本。

Codex 这类 Agent 的价值不是“帮你写几行代码”，而是把很多原本需要跨工具、跨技能、跨人协作的小任务，变成可以委派的后台任务。

这就是 Agent 对知识工作的真正改变：

人不再只是在工具里操作，而是在管理一组持续工作的执行线程。

OpenAI 之前还开源了 Symphony，把 Linear 这类项目管理板变成 coding agents 的控制平面：每个 issue 对应一个 agent workspace，agent 持续跑，人类只审查结果。OpenAI 称某些团队 landed PR 增长达到 500%。

这比“AI 会写代码”更深。它说明软件开发正在从“人使用工具”变成“人调度 Agent 队列”。

四、Microsoft 的信号：Agent 最大瓶颈不是能力，而是控制

如果只有 Meta 和 OpenAI 的动作，我们可以说 Agent 正在进入业务入口和知识工作流。但 Microsoft Build 2026 补上了更关键的一块：治理。

微软在 2026 年 6 月 2 日发布了一组 Agent 信任与控制工具，包括 Agent 365、ASSERT、Agent Control Specification、Foundry tracing/evaluation、runtime DLP 等。

其中最值得关注的是 Agent Control Specification，简称 ACS。

微软对 ACS 的定位很清楚：如果 MCP 标准化了 Agent 如何连接工具，A2A 标准化了 Agent 如何彼此通信，那么 ACS 要标准化 Agent 的安全控制。

ACS 不是再写一句 system prompt：“不要做坏事”。它定义的是 Agent 生命周期里的控制点：

input；
LLM；
state；
tool execution；
output。

也就是说，Agent 在接收输入、调用模型、更新状态、执行工具、输出结果的关键节点，都可以被策略检查、拦截、记录、要求人工确认。

这才是企业真正需要的东西。

企业不缺 demo。企业缺的是：

Agent 能访问哪些数据；
能调用哪些工具；
什么时候必须人工批准；
哪些行为必须阻断；
日志如何审计；
出错后如何回放；
多框架、多模型、多工具怎么统一治理。

微软的 Agent 365 也是这个逻辑：把 Entra、Defender、Purview 放进同一个控制面，让企业能观察、治理、保护不同框架里运行的 Agent。

这说明 Agent 竞争已经进入生产化阶段。生产化的核心不是“模型更聪明”，而是“行为可控”。

五、论文界也在指向同一个结论：治理必须发生在运行时

这不是微软一家在讲。

2026 年 3 月的论文《Runtime Governance for AI Agents: Policies on Paths》提出一个很关键的观点：Agent 的行为是非确定的、路径依赖的，不能只靠设计时规则治理。真正有效的治理对象应该是 execution path，也就是 Agent 已经做了什么、下一步准备做什么、当前组织状态是什么。

这和传统权限控制不同。

传统权限控制问的是：这个用户有没有权限访问这个 API？
Agent 运行时治理问的是：在当前任务路径下、基于前面已经发生的动作，这个 Agent 下一步调用这个工具是否仍然安全？

这就是差异。

比如一个采购 Agent：

单独看“查询供应商报价”是安全的；
单独看“生成采购单”也是安全的；
单独看“发邮件给供应商”也可能安全；
但如果它先被某个供应商网页注入了误导信息，再绕过比价流程，再生成采购单，再发给财务审批，这条路径整体就可能不安全。

所以 Agent 风险不是单点风险，而是路径风险。

另一篇 2026 年 4 月论文《From Governance Norms to Enforceable Controls》也指出，现有治理标准如 ISO/NIST 很重要，但它们本身不会自动变成可执行的 runtime guardrails。需要把治理目标翻译到架构、运行时策略、人工升级、审计证据这些不同层。

这正是当前热点的本质：

AI governance 正在从“写原则”变成“拦动作”。

六、真正的新战场：入口层、执行层、控制层

把 Meta、OpenAI、Microsoft 和论文放在一起看，可以得到一个清晰结构。

层级	代表动作	争夺的东西
入口层	Meta Business Agent 进入 WhatsApp/Instagram/Messenger	谁掌握用户和商家的日常对话入口
执行层	Codex 从编码扩展到知识工作、并行任务、工作流自动化	谁能把任务变成可委派执行线程
控制层	Microsoft ACS、Agent 365、ASSERT、Foundry observability	谁能定义 Agent 的权限、审计、拦截和治理标准

这三层合起来，才是 2026 年 6 月 AI Agent 的真实热点。

不是“Agent 会不会动手”。
而是：

Agent 在哪个入口接单，在什么环境执行，由哪个控制平面监管。

这就是下一代软件平台的雏形。

七、这会改变什么

第一，客服会先被重构。
因为客户咨询天然发生在对话里，而 Agent 最适合从对话中提取意图、调用商品库、预约系统、订单系统。

第二，知识工作会变成“多线程委派”。
未来白领不是打开一个工具做一件事，而是同时把多个任务丢给多个 Agent：一个查资料，一个做表格，一个写报告，一个准备会议纪要。

第三，企业安全边界会前移到 Agent loop。
传统安全系统看进程、网络、文件、账号。Agent 时代还要看：用户意图、工具调用、模型判断、状态变化、审批记录。

第四，软件入口会从 App 变成 Agent。
用户不一定打开 CRM、ERP、表格、客服后台，而是告诉 Agent 要做什么。Agent 再去调用底层系统。

这会带来一个新的平台问题：

未来企业买的可能不是一个个 SaaS，而是能被 Agent 安全调用的一组能力。

八、最大风险：Agent 会让错误变成动作

传统 AI 出错，通常是生成错误内容。
Agent 出错，可能是执行错误动作。

它可能：

给客户错误承诺；
推荐不存在的商品；
错误预约；
错误退款；
泄露客户数据；
调错内部系统；
在错误上下文里关闭销售；
因被注入而执行攻击者意图。

这也是为什么运行时治理会成为热点。

因为你不能只问模型“你安全吗”。你必须在它每次准备行动时问：

这个动作是否符合用户真实意图？
这个工具调用是否超出授权？
这个数据是否能被发出去？
当前路径是否已经偏离策略？
是否需要人工审批？
是否留下足够审计证据？

AI Agent 的关键不是“让 AI 自由发挥”，而是“让 AI 在边界内自主完成任务”。

九、结论：Agent 的未来不是更像人，而是更像可审计员工

过去我们常把 Agent 想象成“数字员工”。但真正的员工不是只靠聪明工作，而是处在组织制度里：有岗位、有权限、有审批、有绩效、有审计、有责任边界。

AI Agent 也会走向这个方向。

2026 年 6 月的最新信号已经很清楚：

Meta 把 Agent 放进商业对话入口；
OpenAI 把 Codex 从编码工具扩成知识工作执行层；
Microsoft 把 Agent 生产化的重点放在控制、评估、审计和治理；
学术界开始把 runtime governance 当成核心问题，而不是附属安全模块。

AI Agent 的下一场战争，不是谁的 Agent 最会动手，而是谁能让 Agent 在真实业务里被安全地允许动手。

RAG文档解析 - pypdf、LlamaParse、DeepDoc、SimpleDirectoryReader到底怎么选？

Tue, 05 May 2026 13:00:00 GMT

最近做 RAG 项目时，很多人第一步就卡在“文档解析”上。

表面看，好像都是把 PDF 里的内容读出来，但不知道要如何选择 pypdf.extract_text()、LlamaParse、DeepDoc、SimpleDirectoryReader 。

SimpleDirectoryReader 是入口
pypdf.extract_text() 是底层文本抽取
LlamaParse 是面向 LLM 的文档解析服务
DeepDoc 是偏重型的文档理解流水线

1. 如何选择?

简单 PDF，本地快速抽字，用 pypdf.extract_text()。

需要保留标题、段落、表格、阅读顺序，做 RAG 数据预处理，优先看 LlamaParse。

扫描件、复杂表格、企业知识库、私有化部署场景，可以看 RAGFlow 里的 DeepDoc。

如果你只是想把一个目录里的文件统一加载进 LlamaIndex，SimpleDirectoryReader 才是入口，但它本身不决定解析质量。

2. 为什么 pypdf 不是“文档理解”

pypdf.extract_text() 的定位很清楚，就是从 PDF 页面对象里提取文字。

from pypdf import PdfReader

reader = PdfReader("a.pdf")
text = ""

for page in reader.pages:
    text += page.extract_text() or ""

它的优势是轻、快、本地、不需要 API key。根据 PyPI，pypdf 在 2026-05-09 发布到 6.11.0，说明这个库仍然很活跃。

但它的边界也很明显：PDF 本身不是为了机器理解设计的。pypdf 官方文档也强调，复杂 PDF 中表格、页眉页脚、阅读顺序、扫描件都会带来问题；如果页面本质是图片，pypdf 并不是 OCR 工具。

新版 pypdf 也支持 extraction_mode="layout"，可以尽量贴近页面布局：

text = page.extract_text(extraction_mode="layout")

但要注意，这仍然不是语义解析。它只能尽力还原“看起来像什么”，不真正知道哪里是标题、哪里是表格、哪里是引用。

3. LlamaParse 的核心价值

LlamaParse 的思路不是“把字抽出来就完事”，而是把复杂文档变成更适合 LLM 使用的数据。

官方文档把它描述为把非结构化文档转成 LLM-ready data 的解析服务，支持文本、Markdown、JSON 等结果，当前 LlamaCloud 还强调 Agentic OCR 和 130+ 格式处理。

这意味着它更适合下面这种链路：

PDF / DOCX / PPTX
        ↓
LlamaParse
        ↓
Markdown / JSON / 页面结构
        ↓
chunking
        ↓
embedding
        ↓
retrieval
        ↓
RAG answer

比如在 LlamaIndex 里，可以让 SimpleDirectoryReader 把 PDF 分发给 LlamaParse：

from llama_parse import LlamaParse
from llama_index.core import SimpleDirectoryReader

parser = LlamaParse(
    api_key="llx-...",
    result_type="markdown",
)

documents = SimpleDirectoryReader(
    "./data",
    file_extractor={".pdf": parser},
).load_data()

我的判断是：如果目标是 RAG，而不是单纯抽字，LlamaParse 通常比 pypdf 更接近生产需求。

但它的问题也现实：云服务、成本、延迟、数据上传、合规审查。这些不是技术小问题，而是项目能不能上线的问题。

4. DeepDoc 更像“文档理解基础设施”

这里的 DeepDoc 指 RAGFlow 中的 DeepDoc。

DeepDoc 做的事情更重。官方 README 里把它分成 vision 和 parser 两部分，vision 里有 OCR、layout recognition、table structure recognition。它还会处理表格旋转、表格结构、图表、页面坐标等问题。

它的 PDF parser 输出不只是纯文本，还包括：

带页面位置的文本块
表格裁剪图和表格内容
图片、caption、图片内文本

所以 DeepDoc 更适合这类场景：

扫描件 PDF
表格密集型财报
合同、说明书、企业制度文档
需要私有化部署的知识库
对引用、溯源、页面定位要求高的系统

但 DeepDoc 的代价也很明显。RAGFlow 官方自托管要求至少 4 核 CPU、16GB RAM、50GB 磁盘，并依赖 Docker。它不是一个随手 pip install 就能结束的轻量 parser，而更像企业 RAG 平台里的文档处理底座。

5. SimpleDirectoryReader 不负责“变聪明”

SimpleDirectoryReader 很容易被误解。

它的作用是读取目录、识别文件类型、调用对应 reader，最后返回 LlamaIndex 的 Document 对象。

from llama_index.core import SimpleDirectoryReader

documents = SimpleDirectoryReader(
    input_dir="./data",
    recursive=True,
    required_exts=[".pdf", ".docx"],
).load_data()

它可以扫描目录、递归读取、限制后缀、附加文件元数据，也可以通过 file_extractor 替换默认解析器。

但它自己不是高级解析器。

所以真正影响质量的是：

.pdf 默认 reader 是谁？
是否替换成 LlamaParse？
是否走 DeepDoc？
是否需要 OCR？
是否要保留表格结构？

SimpleDirectoryReader 更像调度入口，不是解析能力本身。

6. 四者对比

组件	定位	适合场景	优点	主要问题
`pypdf.extract_text()`	底层 PDF 文本抽取	简单 PDF、本地 baseline	免费、本地、快	结构弱，不做 OCR
`LlamaParse`	云端 LLM 文档解析	RAG 数据预处理、复杂 PDF	Markdown/JSON 友好，结构更好	成本、延迟、数据合规
`DeepDoc`	文档理解流水线	扫描件、表格、企业知识库	OCR、布局、表格能力强	部署重、维护成本高
`SimpleDirectoryReader`	文件加载入口	LlamaIndex 多文件导入	简单统一，可扩展	解析质量取决于背后 parser

7. 现在的技术趋势

截至 2026-05-10，文档解析已经不只是“PDF 转文本”了。

RAGFlow 已经把 DeepDoc 放在“深度文档理解”位置，并且在更新记录里提到支持 MinerU、Docling 等文档解析方法。LlamaCloud 也把 Parse、Extract、Classify、Split、Index 拆成更完整的文档智能链路。

这里有个变化值得注意：

过去：提取文本 → 分块 → 向量化
现在：解析结构 → 保留版面 → 表格/图片理解 → 生成可引用 chunk → 检索

也就是说，RAG 的质量问题，很多时候不是 embedding 模型不行，而是文档一开始就被解析坏了。

8. 选型建议

如果只是做 demo：

SimpleDirectoryReader + 默认 PDF reader
或
pypdf.extract_text()

如果要做一个像样的 RAG：

SimpleDirectoryReader + LlamaParse

如果数据不能出内网：

Docling / MinerU / DeepDoc / 自建 OCR pipeline

如果是企业知识库，并且文档质量很差：

RAGFlow + DeepDoc
或者自建 DeepDoc 类似流水线

如果文档主要是电子版 PDF，排版简单，不要一上来就上重型方案。先用 pypdf 做 baseline，把失败样本收集出来，再决定是否升级到 LlamaParse 或 DeepDoc。

结尾

这四个工具不是谁替代谁，而是处在不同的层级，选择的不是最优，而是最合适。

真正合理的架构应该是：

目录入口：SimpleDirectoryReader
简单文件：pypdf
复杂文件：LlamaParse
扫描件/企业复杂文档：DeepDoc
最终目标：高质量 Document / chunk / citation

JavaScript ：从基础语法到 DOM/BOM 进阶（完整版）

Fri, 06 Feb 2026 18:30:00 GMT

第一部分：JavaScript 基础语法

js 的三种书写方式

行内：

<body>
  <button onclick="alert('行内')"></button>
</body>

内部：

<body>
  <script>
    alert("内部");
  </script>
</body>

外部： 外部 js 标签中间不能书写东西

<body>
  <script src="./01.js.html"></script>
</body>

js 的输入输出

输入语法： 页面打印： document.write('页面打印') [编辑] 控制台打印： console.log('控制台打印') [编辑] 弹出界面： console.log('控制台打印') [编辑]

输入语法： prompt('请输入信息') [编辑]

注释

单行注释： //我是单行注释 多行注释： /*我是多行注释*/

变量

变量是用来储存数据的容器，简单理解就是一个盒子

//声明并赋值一个年龄变量
let age = 18;
//输出
alert(age);
//声明一个年龄变量
let age;
//赋值
age = 18;
//输出
alert(age);

数组

定义数组： let arr = [1, 2, 3, 4, 5];console.log(arr); // 输出 [1, 2, 3, 4, 5]

数组的增删改查：

增加元素：
- push ( ) 向数组的末尾添加一个或多个元素 const arr = [1, 2, 3]; arr.push(4);console.log(arr); // 输出 [1, 2, 3, 4]
- unshift ( ) 向数组的开头添加一个或多个元素 const arr = [1, 2, 3]; arr.unshift(0);console.log(arr); // 输出 [0, 1, 2, 3]
- splice ( ) 可以在任意位置插入元素，并且可以同时删除元素。 const arr = [1, 2, 3]; arr.splice(1, 0, 1.5); // 在索引1的位置插入1.5console.log(arr); // 输出 [1, 1.5, 2, 3]
删除元素：
- pop() 从数组的末尾移除一个元素，并返回该元素 const arr = [1, 2, 3];const removed = arr.pop();console.log(arr); // 输出 [1, 2]console.log(removed); // 输出 3
- shift() 从数组的开头移除一个元素，并返回该元素。 const arr = [1, 2, 3];const removed = arr.shift();console.log(arr); // 输出 [2, 3]console.log(removed); // 输出 1
- splice() 可以从数组中删除元素，并且可以同时插入元素。 const arr = [1, 2, 3, 4, 5]; arr.splice(1, 2); // 从索引1开始删除2个元素console.log(arr); // 输出 [1, 4, 5]
修改元素：
- 可以直接通过索引访问和修改数组中的元素 const arr = [1, 2, 3]; arr[1] = 2.5;console.log(arr); // 输出 [1, 2.5, 3]
查询元素：
- 返回数组中某个元素第一次出现的位置索引，如果不存在则返回-1 const arr = [1, 2, 3, 2, 4];const index = arr.indexOf(2);console.log(index); // 输出 1

数据类型

基本数据类型： 基本数据类型是值类型，它们直接存储在栈内存中，而不是通过引用访问。当赋值给另一个变量时，复制的是具体的值，而不是引用。

number: 表示数值，包括整数和浮点数。 let num = 42;
string: 表示文本字符串。 let str = "Hello, world!";
boolean: 表示逻辑值，只有 true 和 false 两个值。 let flag = true;
undifined: 表示尚未赋值的变量或函数返回的未定义值。 let x;console.log(x); // 输出 undefined
null: 表示空值或空对象指针。 let nothing = null;

引用数据类型：

对象: 对象是键值对的集合，是最常用的复合数据类型之一。对象可以包含属性（键值对）和方法（函数）。 let person = { name: "Alice", age: 30, sayHello: function() { console.log("Hello, my name is " + this.name); } };
数组: 数组是一种特殊的对象，用于存储有序的元素列表。数组的元素可以是任何类型的数据。 let numbers = [1, 2, 3, 4, 5];let mixed = ["apple", 42, true, {name: "Alice"}];console.log(numbers[0]); // 输出 1console.log(mixed[3].name); // 输出 "Alice"
函数: 函数也是一种对象，可以作为值进行传递，并且可以作为对象的属性或方法。 function greet(name) { console.log("Hello, " + name + "!"); }

数据转换

隐式转换：

console.log(11 + 11); //number
console.log("11" + 11); //string
console.log("111"); //string
console.log(+"123"); //number
console.log(+"123" + 132); //number

显示转换：

let str = "123";
let num = Number(str); //number
let num1 = +str; //number
let num = 123;
let str = String(num); //string
let str1 = num.toStrign(); //string

运算符

算数运算符：

运算符	描述	示例
+	加法	5 + 3
-	减法	5 - 3
_	乘法	5 _ 3
/	除法	5 / 3
%	取模（求余数）	5 % 3
**	幂运算（次方）	2 ** 3

比较运算符：

运算符	描述	示例
==	等于（值相等即可）	5 == “5”
===	严格等于（值和类型都相等）	5 === “5”
!=	不等于	5 != 3
!==	严格不等于	5 !== “5”
<	小于	5 < 3
>	大于	5 > 3
<=	小于等于	5 <= 5
>=	大于等于	5 >= 5

逻辑运算符：

运算符	描述	示例
&&	逻辑与（AND）	true && false

!	逻辑非（NOT）	!true

一元运算符：

符号	描述	示例
++	前置/后置自增	++x 或 x++
—	前置/后置自减	—x 或 x—
+	正号（强制转换为数字）	+5
-	负号（取反）	-5
!	逻辑非	!true
typeof	获取变量的类型	typeof x
delete	删除对象的属性	delete obj.prop

函数

函数声明： function greet(name) { console.log("Hello, " + name + "!"); } 函数表达式： const greet = function(name) { console.log("Hello, " + name + "!"); }; 立即执行表达式： (function(name) { console.log("Hello, " + name + "!"); })("Charlie"); 箭头函数： const greet = (name) => { console.log("Hello, " + name + "!"); };

对象

对象的创建： 使用字面量方式创建：

//定义对象
let obj = {
  name: "阿伟",
  age: 12,
  phone: 12323232323,
};
console.log(obj);

使用构造函数创建： const person = new Object(); person.name = "Bob"; person.age = 25;

对象增删改查：

增加属性： 使用标点： const person = {}; person.name = "Alice"; person.age = 30; 使用括号： const person = {}; person["name"] = "Alice"; person["age"] = 30;
修改属性： const person = { name: "Alice", age: 30 }; person.age = 31;
删除属性： const person = { name: "Alice", age: 30 }; delete person.age;
查找对象属性： Object.keys(person); // 输出 ["name", "age"] Object.values(person); // 输出 ["Alice", 30] Object.entries(person); // 输出 [["name", "Alice"], ["age", 30]]
遍历对象：

const person = { name: "Alice", age: 30, city: "New York" };
for (const key in person) {
  if (person.hasOwnProperty(key)) {
    console.log(`${key}: ${person[key]}`);
  }
}

第二部分：JavaScript 进阶 DOM 与 BOM

DOM

概念： DOM（文档对象模型）是一种编程接口…[省略重复概念描述]…DOM 把文档视为树形结构。

DOM 树节点：

元素节点、属性节点、文本节点、注释节点、文档节点。

获取 dom 节点

1. 获取 id 名的 dom 节点：

const divById = document.getElementById("my_div");
const divById_ = document.querySelector("#div");
divById.style.backgroundColor = "yellow";

2. 获取 class 类名的 dom 节点:

const divsByClass = document.getElementsByClassName("div");
const divsByClass_ = document.querySelector(".div");
const divsByClass_all = document.querySelectorAll(".div");
divsByClass[0].style.backgroundColor = "lightblue";

*3. 获得 data-为名的节点：

const one = document.querySelector("div");
console.log(one.dataset.id); //1

为 dom 节点添加删除切换 class 类

box.classList.add('active')
box.classList.remove('active')
box.classList.toggle('active')

定时器

延迟函数： setTimeout(greet, 5000); clearTimeout(timeoutId);

事件监听

1. 鼠标事件 click, dblclick, mousedown, mouseup, mousemove, mouseover, mouseout, mouseenter (推荐), mouseleave (推荐)。 2. 键盘事件 keydown, keyup。 3. 表单事件 submit, change, input, focus, blur, select。

事件流

捕获阶段: 从 document 开始向下。
目标阶段: 事件到达目标。
冒泡阶段: 从目标向上。

capture 参数： addEventListener(..., ..., true) 捕获阶段执行。 addEventListener(..., ..., false) 冒泡阶段执行。

阻止冒泡： e.stopPropagation()

事件解绑

button.onclick = null button.removeEventListener('click', fu)

阻止表单默认提交行为

e.preventDefault()

页面尺寸事件

scrollLeft / scrollTop
offsetLeft / offsetTop
clientWidth / clientHeight
offsetWidth / offsetHeight

日期对象

const date = new Date() getFullYear(), getMonth() + 1, getDate(), getDay()。

时间戳

Date.now()
+new Date()
date.getTime()

BOM

定时器函数： setInterval(sayHello, 2000); clearInterval(intervalId);

location 对象： location.href = '跳转地址' location.reload()

history 对象： history.back() / history.forward()

localStorage 对象： localStorage.setItem('test', 'dom') localStorage.getItem('test')

大文件上传：分片上传与断点续传的深度实现

Sun, 01 Feb 2026 22:31:24 GMT

上一篇我们实现了并发控制和安全防线，解决了多文件上传的问题。但如果面试官继续追问：“如果用户要上传一个 2GB 的视频文件怎么办？“或者”上传到一半网络断了，用户需要从头开始吗？“这就需要分片上传和断点续传了。

核心概念

分片上传 - 大文件切割

传统的文件上传是将整个文件一次性发送到服务器，这对于大文件来说有几个致命问题：

浏览器内存溢出：一次性读取 2GB 文件到内存，浏览器直接崩溃
请求超时：大文件传输时间长，容易触发服务器超时限制
失败代价高：上传 99% 时网络断开，所有进度全部丢失

分片上传的核心思路是：将大文件切成小块（如 2MB），逐个上传，最后在服务器端合并。

┌─────────────────────────────────────────────────────┐
│                    2GB 视频文件                       │
└─────────────────────────────────────────────────────┘
                         ↓ Blob.slice()
┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐
│ 2MB  │ │ 2MB  │ │ 2MB  │ │ ...  │ │ 2MB  │  共 1024 个分片
└──────┘ └──────┘ └──────┘ └──────┘ └──────┘
    ↓        ↓        ↓        ↓        ↓
┌─────────────────────────────────────────────────────┐
│              服务器 chunks/{hash}/ 目录               │
│   000000   000001   000002   ...   001023           │
└─────────────────────────────────────────────────────┘
                         ↓ 合并
┌─────────────────────────────────────────────────────┐
│                    完整视频文件                       │
└─────────────────────────────────────────────────────┘

断点续传 - 网络中断恢复

断点续传的原理很简单：上传前先问服务器”你已经收到了哪些分片？“，然后只上传缺失的部分。

// 伪代码：断点续传核心逻辑
const uploadedChunks = await 查询服务器已有分片(fileHash);
for (let i = 0; i < totalChunks; i++) {
  if (uploadedChunks.includes(i)) continue; // 跳过已上传的
  await 上传分片(chunks[i]);
}
await 合并分片();

文件哈希 - 唯一标识

如何判断两次上传的是同一个文件？我们需要计算文件的哈希值作为唯一标识。这里使用 SHA-256 而不是 MD5，因为现代 CPU 对 SHA-256 有硬件加速，实际速度比 MD5 快 2-4 倍。

// 使用 Web Crypto API 计算 SHA-256
const hashBuffer = await crypto.subtle.digest("SHA-256", fileBuffer);

前端实现

我们在现有代码基础上，新增分片上传的核心函数。整体思路是：先计算文件哈希作为唯一标识，然后将文件切成固定大小的分片，逐个上传到服务器，最后通知服务器合并。

分片配置

首先我们需要确定分片的大小。这是一个需要权衡的决策点：

太小（如 256KB）：分片数量多，HTTP 请求开销大，每个请求都有 TCP 握手和 HTTP 头部的额外成本
太大（如 10MB）：单个分片失败后重传代价高，在不稳定网络下容易超时
2MB：适合大多数网络环境，是一个经过实践验证的平衡点

// 分片大小：固定 2MB，简单可靠
const CHUNK_SIZE = 2 * 1024 * 1024;

计算文件哈希

文件哈希是整个分片上传和断点续传的基石。我们使用浏览器原生的 Web Crypto API 来计算 SHA-256 哈希值。这个 API 的优势在于：

原生实现，性能远超 JS 库
现代 CPU 对 SHA-256 有硬件加速（Intel SHA-NI 指令集）
返回的是 ArrayBuffer，需要转换为十六进制字符串便于传输

// 使用 Web Crypto API 计算 SHA-256（比 MD5 更快）
const calculateHash = async (file: File): Promise<string> => {
  // 将文件读取为 ArrayBuffer，这一步会将整个文件加载到内存
  const buffer = await file.arrayBuffer();
  // 调用原生加密 API 计算哈希
  const hashBuffer = await crypto.subtle.digest("SHA-256", buffer);
  // 将 ArrayBuffer 转换为十六进制字符串
  return Array.from(new Uint8Array(hashBuffer))
    .map((b) => b.toString(16).padStart(2, "0"))
    .join("");
};

切割文件为分片

文件切割使用的是 Blob.slice() 方法。这个方法有一个非常重要的特性：它是惰性的（lazy）。调用 slice() 并不会立即读取文件内容到内存，而是创建一个指向原文件特定区域的引用。只有在实际使用这个分片（比如通过 FormData 发送）时，才会真正读取对应的字节。

这意味着即使是一个 10GB 的文件，切成 5000 个分片，内存中也只是存储了 5000 个轻量级的 Blob 引用，而不是 10GB 的数据。

// 使用 Blob.slice() 切割文件，不会一次性读取整个文件到内存
const createChunks = (file: File): Blob[] => {
  const chunks: Blob[] = [];
  let start = 0;
  // 循环切割，每次取 CHUNK_SIZE 大小的片段
  while (start < file.size) {
    // slice(start, end) 返回 [start, end) 区间的数据引用
    chunks.push(file.slice(start, start + CHUNK_SIZE));
    start += CHUNK_SIZE;
  }
  return chunks;
};

上传单个分片（带重试）

网络环境是不可预测的，单个分片上传可能因为网络抖动、服务器繁忙等原因失败。为了提高上传的健壮性，我们实现了指数退避重试策略：

第一次失败：等待 1 秒后重试
第二次失败：等待 2 秒后重试
第三次失败：等待 4 秒后重试
超过最大重试次数：抛出错误，由上层处理

这种策略的好处是，在服务器临时过载的情况下，逐渐增加的等待时间给了服务器恢复的机会，同时避免了频繁重试造成的雪崩效应。

const uploadChunk = async (
  chunk: Blob,
  index: number,
  hash: string,
  filename: string,
  retryCount = 3,
): Promise<void> => {
  // 构建 FormData，这是分片上传的标准格式
  const formData = new FormData();
  formData.append("chunk", chunk);
  formData.append("index", index.toString());
  formData.append("hash", hash);
  formData.append("filename", filename);

  for (let attempt = 0; attempt <= retryCount; attempt++) {
    try {
      await axios.post("http://localhost:3000/upload/chunk", formData, {
        timeout: 60000, // 60秒超时，大分片需要足够的传输时间
      });
      return; // 成功则返回
    } catch (error) {
      if (attempt === retryCount) throw error;
      // 指数退避：1s, 2s, 4s
      const delay = 1000 * Math.pow(2, attempt);
      await new Promise((r) => setTimeout(r, delay));
    }
  }
};

完整上传流程（含断点续传）

现在我们把所有模块组合起来，实现完整的上传流程。这个流程包含六个关键步骤：

计算哈希：生成文件的唯一标识，用于后续的分片管理和断点续传
初始化状态：在响应式 Map 中记录上传状态，用于 UI 展示
查询已有分片：这是断点续传的核心，询问服务器已经收到了哪些分片
上传缺失分片：跳过已存在的分片，只上传缺失的部分
请求合并：所有分片上传完成后，通知服务器将分片合并为完整文件
更新状态：标记上传成功或失败

整个过程中，我们使用 Vue 3 的 reactive 来管理上传状态。这里有一个技巧：使用 Map 而不是普通对象，是因为 Map 的键可以是任意值（我们用文件哈希作为键），而且 Vue 3 对 Map 有完整的响应式支持。

// 上传状态接口定义
interface UploadState {
  file: File;
  hash: string;
  status: "uploading" | "success" | "error";
  progress: number;
  error?: string;
}

// 使用 Map 存储多个文件的上传状态，键为文件哈希
const uploadStates = reactive<Map<string, UploadState>>(new Map());

const uploadFile = async (file: File) => {
  // 1. 计算文件哈希 - 这是后续所有操作的基础
  const hash = await calculateHash(file);
  const chunks = createChunks(file);
  const totalChunks = chunks.length;

  // 2. 初始化上传状态 - 用于 UI 展示
  uploadStates.set(hash, {
    file,
    hash,
    status: "uploading",
    progress: 0,
  });

  try {
    // 3. 【断点续传关键】查询服务器已有哪些分片
    // 如果是新上传，返回空数组；如果是续传，返回已有的分片索引
    const res = await axios.get(`http://localhost:3000/upload/status/${hash}`);
    const uploaded = new Set<number>(res.data.uploadedChunks);

    console.log(
      `文件 ${file.name} 已上传 ${uploaded.size}/${totalChunks} 个分片`,
    );

    // 4. 只上传缺失的分片 - 这就是断点续传的实现
    let completed = uploaded.size;
    for (let i = 0; i < totalChunks; i++) {
      if (uploaded.has(i)) continue; // 跳过已上传的分片

      await uploadChunk(chunks[i], i, hash, file.name);
      completed++;

      // 实时更新进度，让用户看到上传进展
      const state = uploadStates.get(hash);
      if (state) {
        state.progress = Math.round((completed / totalChunks) * 100);
      }
    }

    // 5. 所有分片上传完成，请求服务器合并
    // 传入预期大小用于服务器端校验
    await axios.post("http://localhost:3000/upload/merge", {
      hash,
      filename: file.name,
      totalChunks,
      expectedSize: file.size,
    });

    // 6. 标记上传成功
    const state = uploadStates.get(hash);
    if (state) {
      state.status = "success";
      state.progress = 100;
    }
  } catch (error) {
    // 错误处理：记录错误信息，UI 可以展示重试按钮
    const state = uploadStates.get(hash);
    if (state) {
      state.status = "error";
      state.error = error instanceof Error ? error.message : "上传失败";
    }
  }
};

进度显示组件

有了上传状态数据，我们需要一个组件来展示。这个组件遍历 uploadStates Map，为每个正在上传的文件显示进度条和状态。

组件的几个设计要点：

使用 v-for 遍历 Map 时，解构为 [hash, state] 键值对
进度条使用 CSS width 百分比实现，配合 transition 实现平滑动画
错误状态下显示重试按钮，提升用户体验

<template>
  <div class="upload-list">
    <div v-for="[hash, state] in uploadStates" :key="hash" class="upload-item">
      <div class="file-info">
        <span class="filename">{{ state.file.name }}</span>
        <span class="status" :class="state.status">
          {{ state.status === 'uploading' ? '上传中' : state.status === 'success' ? '成功' : '失败' }}
        </span>
      </div>

      <div class="progress-bar">
        <div
          class="progress-fill"
          :style="{ width: state.progress + '%' }"
          :class="{ error: state.status === 'error' }"
        ></div>
      </div>
      <span class="progress-text">{{ state.progress }}%</span>

      <div v-if="state.status === 'error'" class="error-info">
        <span>{{ state.error }}</span>
        <button @click="retryUpload(state.file)">重试</button>
      </div>
    </div>
  </div>
</template>

<style scoped>
.upload-item {
  padding: 12px;
  background: #f9f9f9;
  border-radius: 8px;
  margin-bottom: 10px;
}
.progress-bar {
  height: 8px;
  background: #e0e0e0;
  border-radius: 4px;
  overflow: hidden;
  margin: 8px 0;
}
.progress-fill {
  height: 100%;
  background: linear-gradient(90deg, #4caf50, #8bc34a);
  transition: width 0.2s;
}
.progress-fill.error {
  background: #f44336;
}
.status.uploading { color: #1976d2; }
.status.success { color: #4caf50; }
.status.error { color: #f44336; }
</style>

后端实现

后端需要新增三个核心接口来配合前端的分片上传：接收分片、查询状态、合并分片。此外还需要处理文件名安全和过期分片清理。

目录结构

在开始编码前，我们先明确服务器端的文件组织结构。分片临时存储在 chunks/ 目录下，以文件哈希为子目录名，每个分片以索引命名。合并完成的文件存储在 uploads/ 目录。

server/
  ├── uploads/      # 完整文件存储
  ├── chunks/       # 临时分片存储
  │   └── {hash}/   # 每个文件的分片目录
  │       ├── 000000
  │       ├── 000001
  │       └── ...
  └── index.js

接收分片接口

这是分片上传的入口接口。每次请求接收一个分片，将其存储到对应的目录中。

关键设计点：

以哈希为目录名：相同文件的分片会自动归类到同一目录，便于管理和合并
零填充命名：使用 padStart(6, '0') 确保分片按数字顺序排列，避免 1, 10, 2 这样的字典序问题
使用 fs.renameSync：Multer 已经将文件保存到临时目录，我们只需要移动到目标位置，比复制更高效

// 首先确保分片存储目录存在
const chunksDir = path.join(__dirname, "chunks");
if (!fs.existsSync(chunksDir)) {
  fs.mkdirSync(chunksDir);
}

// 接收单个分片
app.post("/upload/chunk", upload.single("chunk"), (req, res) => {
  const { index, hash, filename } = req.body;

  // 参数校验：确保必要信息都已提供
  if (!req.file || !hash || index === undefined) {
    return res.status(400).json({ msg: "参数不完整" });
  }

  // 以文件哈希为文件夹名存储分片
  // 这样相同文件的分片会自动归类在一起
  const chunkDir = path.join(chunksDir, hash);
  if (!fs.existsSync(chunkDir)) {
    fs.mkdirSync(chunkDir, { recursive: true });
  }

  // 使用零填充命名（000000, 000001...），确保排序正确
  // 6位数字支持最多 999999 个分片，对于 2MB 分片大小，可支持约 2TB 文件
  const chunkPath = path.join(chunkDir, String(index).padStart(6, "0"));
  fs.renameSync(req.file.path, chunkPath);

  res.json({ msg: "分片上传成功", index: parseInt(index) });
});

查询上传状态接口（断点续传核心）

这个接口是实现断点续传的关键。前端在开始上传前调用此接口，获取服务器已经收到的分片列表，然后跳过这些分片，只上传缺失的部分。

接口设计非常简单：根据文件哈希找到对应的分片目录，读取目录中的所有文件名（即分片索引），返回给前端。如果目录不存在，说明是新上传，返回空数组。

// 查询已上传的分片列表
// 这个接口是断点续传的核心，前端据此决定哪些分片需要上传
app.get("/upload/status/:hash", (req, res) => {
  const { hash } = req.params;
  const chunkDir = path.join(chunksDir, hash);

  // 目录不存在说明是新上传，返回空数组
  if (!fs.existsSync(chunkDir)) {
    return res.json({ uploadedChunks: [] });
  }

  // 读取目录中的所有分片文件，提取索引
  // 过滤条件：只保留纯数字命名的文件（排除 .DS_Store 等系统文件）
  const uploadedChunks = fs
    .readdirSync(chunkDir)
    .filter((name) => /^\d+$/.test(name))
    .map((name) => parseInt(name))
    .sort((a, b) => a - b);

  res.json({ uploadedChunks });
});

合并分片接口

当所有分片上传完成后，前端调用此接口通知服务器进行合并。这是整个上传流程中最关键的一步，需要处理多个边界情况：

分片完整性检查：确保收到的分片数量与预期一致
流式合并：使用 createWriteStream 逐个写入分片，避免一次性加载所有分片到内存
大小校验：合并后检查文件大小是否与预期一致，防止数据丢失
安全校验：复用现有的二进制魔数校验，确保文件类型合法
清理工作：合并成功后删除临时分片目录，释放磁盘空间
错误回滚：如果合并过程中出错，删除不完整的目标文件

// 合并所有分片为完整文件
app.post("/upload/merge", express.json(), async (req, res) => {
  const { hash, filename, totalChunks, expectedSize } = req.body;
  const chunkDir = path.join(chunksDir, hash);

  // 首先检查分片目录是否存在
  if (!fs.existsSync(chunkDir)) {
    return res.status(400).json({ msg: "分片目录不存在" });
  }

  // 检查分片完整性：实际分片数量必须等于预期数量
  const existingChunks = fs
    .readdirSync(chunkDir)
    .filter((name) => /^\d+$/.test(name))
    .sort((a, b) => parseInt(a) - parseInt(b));

  if (existingChunks.length !== totalChunks) {
    return res.status(400).json({
      msg: "分片不完整",
      expected: totalChunks,
      received: existingChunks.length,
    });
  }

  // 安全处理文件名，防止路径穿越攻击
  const safeFilename = sanitizeFilename(filename);
  const filePath = path.join(uploadDir, `${Date.now()}-${safeFilename}`);

  try {
    // 使用流式写入合并分片，避免内存溢出
    // 对于 2GB 的文件，如果一次性读取所有分片，内存会直接爆掉
    const writeStream = fs.createWriteStream(filePath);

    // 按顺序读取并写入每个分片
    for (let i = 0; i < totalChunks; i++) {
      const chunkPath = path.join(chunkDir, String(i).padStart(6, "0"));
      const chunkBuffer = fs.readFileSync(chunkPath);
      writeStream.write(chunkBuffer);
    }

    // 等待写入流完成
    await new Promise((resolve, reject) => {
      writeStream.on("finish", resolve);
      writeStream.on("error", reject);
      writeStream.end();
    });

    // 验证合并后的文件大小是否与预期一致
    // 这一步可以检测出传输过程中的数据丢失
    const stats = fs.statSync(filePath);
    if (expectedSize && stats.size !== expectedSize) {
      fs.unlinkSync(filePath);
      return res.status(400).json({ msg: "文件大小不匹配，合并失败" });
    }

    // 复用现有的二进制魔数校验，确保文件类型合法
    // 这是最后一道安全防线，防止恶意文件伪装
    const buffer = Buffer.alloc(8);
    const fd = fs.openSync(filePath, "r");
    fs.readSync(fd, buffer, 0, 8, 0);
    fs.closeSync(fd);

    if (!isJPG(buffer) && !isPNG(buffer) && !isPDF(buffer)) {
      fs.unlinkSync(filePath);
      return res.status(403).json({ msg: "安全警告：文件类型验证失败" });
    }

    // 合并成功，清理临时分片目录
    fs.rmSync(chunkDir, { recursive: true });

    res.json({
      msg: "文件合并成功",
      filename: path.basename(filePath),
      size: stats.size,
    });
  } catch (error) {
    // 出错时清理可能已创建的不完整文件
    if (fs.existsSync(filePath)) {
      fs.unlinkSync(filePath);
    }
    res.status(500).json({ msg: "合并失败: " + error.message });
  }
});

文件名安全处理

文件名安全是一个容易被忽视但非常重要的安全点。攻击者可能通过构造特殊的文件名来实现路径穿越攻击（Path Traversal），例如 ../../etc/passwd 这样的文件名，如果不经处理直接拼接路径，可能会将文件写入到系统敏感目录。

我们的安全处理策略包括：

Unicode 规范化：防止通过不同编码形式绕过检查
移除危险字符：删除 <>:"/\|?* 等在文件系统中有特殊含义的字符
提取文件名：使用 path.basename() 确保只保留文件名部分
长度限制：过长的文件名可能导致文件系统错误

const sanitizeFilename = (filename) => {
  // Unicode NFC 规范化，防止字符编码绕过
  // 例如 é 可以表示为单个字符或 e + 重音符的组合
  let safe = filename.normalize("NFC");

  // 移除在 Windows/Linux 文件系统中有特殊含义的危险字符
  // 同时移除控制字符 (0x00-0x1f)
  safe = safe.replace(/[<>:"/\\|?*\x00-\x1f]/g, "_");

  // 只保留文件名部分，丢弃任何路径信息
  // 这是防止路径穿越攻击的关键步骤
  safe = path.basename(safe);

  // 限制文件名长度，大多数文件系统限制在 255 字节
  // 我们保守地限制在 200 字符
  if (safe.length > 200) {
    const ext = path.extname(safe);
    safe = safe.slice(0, 200 - ext.length) + ext;
  }

  return safe || "unnamed";
};

启动时清理过期分片

用户可能在上传过程中关闭浏览器，或者上传失败后没有重试，这些情况会在服务器上留下未完成的分片目录。如果不清理，随着时间推移会占用大量磁盘空间。

我们的策略是在服务器启动时执行一次清理，删除超过 24 小时的未完成上传。这个时间阈值的选择考虑了：

太短：用户可能第二天继续上传，不应该删除
太长：占用磁盘空间
24 小时：一个合理的平衡点

// 清理超过 24 小时的未完成上传
// 这些是用户中途放弃或上传失败后遗留的分片
const cleanupOrphanedChunks = () => {
  const maxAgeMs = 24 * 60 * 60 * 1000; // 24 小时
  const now = Date.now();

  if (!fs.existsSync(chunksDir)) return;

  const sessions = fs.readdirSync(chunksDir);

  for (const sessionId of sessions) {
    const sessionPath = path.join(chunksDir, sessionId);
    try {
      // 检查目录的最后修改时间
      const stats = fs.statSync(sessionPath);
      if (now - stats.mtimeMs > maxAgeMs) {
        // 超过 24 小时，删除整个分片目录
        fs.rmSync(sessionPath, { recursive: true });
        console.log(`[清理] 已删除过期分片: ${sessionId}`);
      }
    } catch (error) {
      console.error(`[清理] 处理 ${sessionId} 时出错:`, error.message);
    }
  }
};

// 服务器启动时执行一次清理
cleanupOrphanedChunks();

完整流程图

最后，让我们通过一个完整的流程图来回顾整个分片上传和断点续传的过程：

用户选择文件
     ↓
计算文件 SHA-256 哈希（生成唯一标识）
     ↓
查询服务器 GET /upload/status/{hash}
     ↓
获取已上传分片列表 [0, 1, 2, ...]
     ↓
切割文件为 2MB 分片
     ↓
循环上传缺失分片 POST /upload/chunk
  ├── 分片 0 (已存在，跳过)
  ├── 分片 1 (已存在，跳过)
  ├── 分片 2 → 上传 → 更新进度
  ├── 分片 3 → 上传 → 更新进度
  └── ...
     ↓
所有分片上传完成
     ↓
请求合并 POST /upload/merge
     ↓
服务器合并分片 + 大小校验 + 安全校验
     ↓
清理临时分片目录
     ↓
返回上传成功

下一篇我们将实现文件管理功能：列表展示、下载、删除，完成文件上传系统的最后一块拼图。

如何用AI写代码? vibe coding

Mon, 05 Jan 2026 13:00:00 GMT

写在前面

vibe coding 不是“让 AI 替我写代码”这么简单。

更准确地说，它是一种新的软件生产方式：人把意图、约束、上下文、验收标准和工程判断交给 AI，AI 把这些东西转化成原型、代码、文档、测试和可运行系统。它降低了从想法到代码的门槛，也放大了每一个模糊需求、错误假设和缺失测试。

所以我对 vibe coding 的理解不是“更随意地写代码”，而是“更严肃地表达需求”。过去工程师的主要成本在写代码，现在主要成本开始转移到：定义问题、拆解模块、写清约束、审查结果、建立测试、处理联调、沉淀规则、持续迭代。

AI 可以承担大量执行工作，但它不能承担责任。真正的责任仍然在使用 AI 的人身上。

1. vibe coding 到底是什么

Collins Dictionary 把 “vibe coding” 选为 2025 年年度词，并把它描述为一种通过 AI 把自然语言转成计算机代码的软件开发方式。这个词由 Andrej Karpathy 在 2025 年初带火，用来描述一种“把需求说出来，让大模型生成代码，然后持续对话迭代”的开发状态。

但是在工程项目里，不能只理解它的“vibe”。如果只是凭感觉让 AI 写，最后会得到一个看起来能跑、但没人真正理解、没人敢改、没人敢上线的系统。

我更愿意把 vibe coding 分成两层：

第一层是原型阶段的 vibe：范围可以宽，方向可以发散，重点是快速探索可能性。比如 UI 原型、交互方式、页面结构、产品概念、信息架构，这些阶段可以让 AI 多给方案，多试风格，多做变体。

第二层是工程阶段的 coding：范围必须收窄，约束必须清晰，结果必须可验证。比如登录、支付、权限、数据库、AI agent 状态流转、任务队列、文件上传、安全策略，这些不能只靠感觉，必须靠规格、测试和审查。

一句话：vibe coding 的前半段可以发散，后半段必须收敛。

2. 我理解的开发过程：从原型到系统

一个实际项目用 AI 开发，大概会经历两条线。

第一条线是产品和 UI 线。

它通常不是一次到位，而是从草图开始：先做一个能表达主流程的粗糙原型，再补状态、补页面、补交互细节；需求变化后继续调整，直到团队能围绕同一个可见版本讨论。

这个阶段的重点不是代码质量，而是把想法变成可讨论的东西。很多需求只靠文字说不清楚，必须先看到页面、流程、状态、边界情况，团队才知道自己到底要什么。

第二条线是工程实现线。

这条线不能直接从原型跳到代码。更稳的顺序是：先把原型翻译成可实现方案，再拆出模块、接口、数据、权限和状态；随后从一个最小闭环开始实现，逐步补后端、前端、联调、AI 能力、测试、上线和反馈。

这里最重要的是“可实现”。原型是想象，方案是桥梁，代码是落地。没有方案直接让 AI 写，很容易得到一个局部漂亮、整体混乱的项目。

如果项目里包含真正的 AI 能力，我现在会把投入成本大概排成这样：

AI 搭建 > 文档 > 测试 > 前后端联调 > 后端非 AI 部分 > 前端。

这不是绝对规律，但它提醒我们一件事：AI 开发里最贵的往往不是“代码从无到有”，而是“系统从能演示到可信赖”。页面和接口可以很快生成，真正消耗时间的是输出可控、状态可追踪、失败可恢复、测试能覆盖、协议能联调、文档能支撑后续迭代。

所以 AI 开发项目应该从小闭环开始。

不要一开始就让 AI 实现一个完整 SaaS、完整 agent、完整后台、完整权限、完整支付。先做一个最小闭环：一个用户、一个核心流程、一个可验证结果、一个失败处理、一个测试入口。小闭环跑通以后，再扩展模块。

3. 倒金字塔：越往后越窄

我认为 vibe coding 的形状是一个倒金字塔。

最开始很宽：想法、风格、交互、模块边界、技术选型都可以开放，让 AI 帮你头脑风暴。

中间开始收窄：确定页面、数据结构、接口协议、权限模型、状态机、任务拆分。

最后必须很窄：一个 bug、一个接口、一个组件、一个测试、一个边界条件、一个 PR。

很多 AI 开发失败，是因为一直停留在倒金字塔的上半部分。需求一直很宽，提示词一直很泛，验收一直很模糊，却期待 AI 交付一个稳定系统。

AI 的选择空间越大，它越容易走向你没想到的方向。做原型时，这是优点；做工程时，这是风险。

约束不是限制创造力，约束是把 AI 的能力导向正确结果。

4. AI 写代码的核心材料

用 AI 写代码，不是只写一句 prompt。比较稳定的组合应该是：

可实现文档 + 任务提示词 + 项目公共规则 + 可复用 Skill + 插件和工具 + review。

其中最重要的是“可实现文档”。

一个可实现文档至少应该回答：

这个功能解决什么问题？
用户路径是什么？
哪些状态必须出现？
哪些边界条件必须处理？
涉及哪些页面、接口、表、任务、权限？
输入输出是什么？
不做什么？
怎么验收？
怎么测试？

AI 不是读心工具。你给它“做一个导入功能”，它会自行决定文件格式、校验方式、失败策略和页面交互；你给它“在运营后台增加客户线索 CSV 导入，先预览前 20 行，不预览不落库，确认后创建 import job，重复邮箱跳过并返回失败清单，复用现有批处理队列，测试覆盖空文件、字段缺失、部分成功和重复提交”，它才有可能做出接近工程要求的结果。

5. 一个好提示词的结构

我现在不太建议把提示词理解成固定八股。更好的方式是按问题裁剪，但大部分工程任务都离不开五类信息：

目标：这次到底要交付什么。

上下文：现有系统里已经有什么，不要让 AI 从零发明。

边界：哪些可以改，哪些不能碰，哪些场景暂时不做。

验收：怎样证明它完成了，最好能落到命令、页面路径或测试用例。

输出：最后要汇报什么，避免 AI 只说“完成了”。

例如：

你接手的是一个 B2B CRM 的运营后台。

目标：
新增“客户线索 CSV 导入”的最小闭环：上传文件 -> 后端解析 -> 页面预览 -> 用户确认 -> 批量写入 -> 返回导入结果。

先读代码：
- imports 相关 route
- lead service
- 数据库 schema
- 现有后台表格组件
- 项目里已有的 job / queue 用法

这次只做：
- 支持 UTF-8 CSV。
- 必填字段是 companyName、contactName、email。
- 预览阶段只校验字段和格式，不写数据库。
- 确认导入后创建 import job。
- 重复 email 跳过，并在结果里返回行号和原因。

这次不做：
- Excel 导入。
- 字段自由映射。
- 超大文件分片上传。
- 导入历史详情页。

实现约束：
- 复用现有后台上传组件和错误提示样式。
- 不引入新的 CSV 解析库，除非项目没有可用方案，并说明原因。
- 不改 lead 表的无关字段。
- 后端错误格式必须和现有 API 保持一致。

验收：
- 一个正常 CSV 可以预览并导入。
- 缺少 email 的行不能导入，并在预览里标出原因。
- 重复提交不会创建重复线索。
- 至少运行导入相关的单元测试或接口测试。

最后输出：
- 修改了哪些文件。
- 新增或调整了哪些接口。
- 运行了什么验证。
- 哪些能力仍然没做。

这类提示词看起来长，但它真正减少的是 AI 的自由发挥空间。不是每个任务都要写这么多；小 bug 可以短，大模块必须清楚。

提示词不是魔法，它更像一份压缩版任务单。任务单越清楚，AI 越少替你做危险的业务假设。

6. 复杂模块不要一次追求完美

复杂模块适合循序渐进，不适合一口吃完。

以“AI 工单摘要”为例：

第一步，能用：

客服在工单详情页点击“生成摘要”，系统把对话内容发给模型，并返回一段可编辑摘要。

第二步，好用：

增加生成中状态、失败重试、空对话提示、摘要字数限制，以及人工编辑后的保存入口。

第三步，快用：

对同一工单的短时间重复生成做缓存；对长对话先做截断或分段摘要，避免接口超时和成本失控。

第四步，爱用：

支持按“客户情绪、待办事项、风险等级”拆分摘要，并把高风险工单自动推到主管审核队列。

这个顺序的关键是：先闭环，再体验；先正确，再优雅；先可验证，再扩展。

很多人用 AI 写代码时容易反过来：一开始就让 AI 生成“完整、优雅、可扩展、企业级、支持所有场景”的实现。结果就是代码量巨大、抽象过早、bug 很隐蔽、review 很痛苦。

AI 会放大你的表达。如果你的目标是“全都要”，它就会真的给你一堆东西。

7. SDD：让规格成为源头

在 AI 开发里，SDD 可以理解为 Spec-Driven Development，也就是规格驱动开发。

传统开发里，代码往往是最主要的事实来源；而在 AI 协作里，规格应该变成更靠前的事实来源。因为 AI 生成代码的速度太快，如果没有规格约束，代码会比理解先增长。

一个实用的 SDD 不一定很重。它可以很短，但必须能指导实现。

我建议每个模块至少有一份这样的规格：

# 模块名称

## 目标
这个模块解决什么问题，最终用户是谁。

## 非目标
明确这次不做什么，避免 AI 自行扩展。

## 用户流程
用步骤描述用户从入口到结果的路径。

## 数据模型
涉及哪些表、字段、状态、枚举。

## 接口契约
请求、响应、错误码、权限要求。

## 状态流转
列出 pending / running / succeeded / failed / canceled 等状态，以及谁能触发状态变化。

## 边界条件
空数据、重复提交、超时、并发、权限不足、外部服务失败。

## 验收标准
什么情况算完成，什么情况算失败。

## 测试计划
单元测试、集成测试、端到端测试、手工验证路径。

对 AI 模块尤其要写状态流转。比如一次 AI run，至少要明确：

run 如何创建；
run 什么时候进入 running；
工具调用是否可重试；
用户取消时如何处理；
模型超时如何处理；
部分输出是否保存；
失败后用户看到什么；
日志和 trace 存在哪里；
哪些数据不能进入 prompt；
哪些动作必须人工确认。

AI 模块最怕“看起来能跑”。看起来能跑不代表可恢复、可追踪、可审计、可扩展。

8. CLAUDE.md：公共规则要写下来

公共提示词应该沉淀到 CLAUDE.md 或类似的项目规则文件里。

它不应该写成一篇大作文，而应该写成稳定、简洁、可验证的工程规则。比如：

## 四个工作原则

### 1. 编码前思考

不要假设，不要隐藏困惑，必须呈现关键权衡。

- 开始修改前，先用 2-5 句话说明理解、假设和可能风险。
- 如果需求存在多种解释，列出解释并说明推荐选项；无法合理判断时先问清楚。
- 如果用户要求的方案明显复杂、脆弱或与现有架构冲突，先提出异议并给出更简单方案。
- 不确定数据库字段、路由前缀、认证语义、AI run 状态流转时，必须先查代码再改。

### 2. 简洁优先

用最少代码解决当前问题，不做过度推测。

- 不添加需求之外的功能、配置项、抽象层或通用框架。
- 不为一次性逻辑创建抽象。
- 不为当前业务不可能发生的场景堆叠错误处理。
- 如果实现开始变得臃肿，停下来简化；资深工程师会觉得复杂就重写得更直接。
- 优先复用现有 services、routes、stores、components 和类型定义。

### 3. 精准修改

只碰必须碰的代码，只清理自己造成的问题。

- 每一行修改都必须能直接追溯到用户请求。
- 不顺手重构、不顺手格式化、不改相邻无关代码。
- 匹配所在文件现有风格，即使你更偏好另一种写法。
- 发现无关死代码或坏味道时，在回复中指出即可，不主动删除。
- 如果你的改动导致导入、变量、函数变成孤儿代码，要同步删除这些由本次改动造成的无用代码。

### 4. 目标驱动执行

把任务转化为可验证目标，并循环验证直到达成。

- 修 bug: 先明确复现条件，再修复，再验证复现条件消失。
- 加校验: 优先补充或运行覆盖无效输入的检查。
- 重构: 保证重构前后的行为和测试结果一致。
- 多步骤任务要写短计划，每步包含验证方式。
- 完成前至少运行与改动相关的最小验证；如果不能运行，说明原因和剩余风险。

9. Skill：把经验变成可复用能力

Skill 的价值在于跨会话、跨项目复用经验。

如果你发现自己经常复制同一段提示词，就应该考虑把它变成 Skill。比如：

code-review skill：检查 bug、边界条件、测试缺口和安全风险；
api-design skill：根据项目规范设计接口；
db-migration skill：检查 migration、索引、回滚和兼容性；
ai-run-debug skill：排查 agent 状态、tool call、trace 和 prompt；
frontend-polish skill：检查移动端、空状态、加载态、错误态、可访问性；
release-check skill：上线前检查环境变量、迁移、监控和回滚。

一个 Skill 可以很简单：

---
name: code-quality-review
description: 通用代码质量审查 skill。用于 review 代码、检查封装性/复用性/可维护性、发现过度抽象、职责混乱、边界泄漏、错误处理薄弱、类型设计问题、可读性问题，或在提交前做工程质量检查。适用于前端、后端、全栈、脚本和库代码。
---

# Code Quality Review

## 工作方式

1. 先确认本次审查范围：整个 diff、某个文件、某个模块，还是某个设计方案。
2. 先读项目约定：`CLAUDE.md`、README、package scripts、测试配置、lint/format 配置。
3. 再读代码入口和调用链，不只看被改文件。重点看数据从哪里来、在哪里变形、在哪里产生副作用。
4. 以 bug、维护风险和边界问题优先，不把个人风格偏好伪装成问题。
5. 输出时按严重程度排序：正确性/安全性/数据一致性 > 可维护性 > 可读性 > 风格。
6. 如果用户要求修改，就直接修；如果用户只要求 review，就只给 findings，不擅自改代码。

## 审查维度

- 职责：函数、组件、service、hook、class 是否各自只做一类事。
- 边界：UI、业务、数据访问、网络、存储、权限、配置是否混在一起。
- 抽象：是否解决了真实重复和复杂度，还是为了“看起来高级”而抽象。
- 复用：重复逻辑是否该抽 helper；相似但语义不同的逻辑是否不该硬合并。
- 类型：类型是否表达业务不变量，是否滥用 `any`、宽泛 object、字符串魔法值。
- 错误处理：是否吞错、重复 catch、把用户错误当系统错误、丢失上下文。
- 状态：是否存在竞态、旧请求污染新状态、缓存失效、状态来源不唯一。
- 数据：是否有 N+1、分页缺失、事务边界缺失、跨租户/跨用户泄漏。
- 可测试性：核心逻辑是否被 UI/IO 绑死，是否有可独立验证的边界。

## 何时读取参考

需要更细的检查清单时，读取 `references/review-checklist.md`。

## 输出格式

如果是 review，使用：

```text
发现：
- [P1] 问题标题：文件:行。说明影响、触发条件、建议修复。
- [P2] ...

开放问题：
- ...

总体判断：
...

如果没有发现问题，明确说“没有发现明确 bug 或高风险设计问题”，再列剩余风险，例如“未运行测试”或“只审查了局部 diff”。

修改原则

小步改动，保持现有项目风格。
优先删除不必要复杂度，再考虑新增抽象。
不做无关重构，不顺手格式化全文件。
把新抽象命名成业务语义，不用 manager、helper、utils 兜底命名。


Skill 的本质是把个人经验产品化。它让 AI 不只是“会写代码”，而是逐渐学会“按你的工程习惯工作”。

## 10. 四个工作原则

如果把上面的内容再压缩，我会把 vibe coding 的工程纪律总结成四条。这四条不是为了限制 AI，而是为了让 AI 的速度不会冲垮项目质量。

### 10.1 先把不确定性摊开

AI 开发最容易出问题的地方，不是模型不会写，而是它会把不确定的东西写成确定的代码。

所以在动手前，应该先把三件事说清楚：

- 我理解这次要解决什么问题；
- 我基于哪些现有事实做判断；
- 还有哪些地方不确定，准备怎么验证。

比如用户说“给报表加一个导出功能”，这句话至少有几种解释：导出当前筛选结果、导出全部数据、导出异步任务、导出带权限脱敏的数据。AI 如果直接写，很可能选错。

更好的工作方式是先收窄：

```md
我先确认导出语义：这里应该导出当前筛选后的结果，而不是全量数据；导出字段沿用表格列，但联系电话和邮箱需要脱敏；文件生成走现有 report job，避免同步接口超时。接下来我会先查现有报表查询和 job 代码，再改导出入口。

特别是这些内容，不能靠猜：

数据库字段；
路由前缀；
认证语义；
权限边界；
AI run 状态流转；
队列重试策略；
外部服务回调；
支付和订单状态；
文件上传和存储路径。

AI 最危险的能力不是不会做，而是它会在不知道的时候继续编。

10.2 先用小解法打通

AI 很擅长把小需求写成大系统。它会自然倾向于补配置、补抽象、补扩展点、补框架感。问题是很多扩展点在当前阶段根本用不上，只会增加 review 和维护成本。

所以默认策略应该是：先写一条最短可验证路径。

比如要做“库存不足提醒”，第一版不需要先做一套通用规则引擎。更合理的是：

后台配置一个固定阈值；
每次库存变更后检查是否低于阈值；
低于阈值时写入一条提醒；
前端在商品详情展示提醒状态；
测试覆盖库存从高到低、重复提醒、库存恢复。

等到真的出现多个仓库、多个品类、多个阈值策略，再考虑抽象。不要为了“未来可能”牺牲当前清晰度。

资深工程师对 AI 代码的一个重要动作，就是把“看起来很完整”的代码压回“刚好够用”的代码。

10.3 控制改动半径

AI 一次能改很多文件，这既是能力也是风险。工程上要关心的不只是功能有没有做出来，还要关心 diff 能不能被人理解。

我会用“改动半径”来判断一次 AI 修改是否健康：

半径 1：只改当前函数或组件，最容易 review；
半径 2：改当前模块的 service、route、test，可以接受；
半径 3：跨模块改公共类型、状态、协议，需要更强测试；
半径 4：顺手重构架构、格式化大量文件，通常应该拆开。

比如修一个“筛选条件刷新后丢失”的 bug，合理范围可能是查询参数同步和对应测试；如果 AI 顺手重写了整个表格状态管理，就算最后能跑，也会让风险变大。

发现无关问题可以记录在回复里，或者单独开任务。不要把“我顺手看到了”变成“我顺手改了”。

10.4 用验证关门

AI 说完成了没有意义，验证完成才有意义。

不同类型任务应该有不同的关门方式：

修 bug：复现条件消失；
做接口：请求、响应、错误码和权限都被验证；
做 UI：加载、空态、错误态、移动端至少看过关键路径；
做 AI 功能：正常输出、工具失败、模型超时、人工取消都能解释；
做重构：行为不变，测试结果不变。

比如修“订单列表偶发重复行”，不要只说“我加了去重”。更完整的闭环应该是：

复现：快速切换分页和筛选时，同一个订单会被追加两次。
根因：请求返回顺序不可控，旧请求覆盖了新筛选状态。
修复：给列表请求增加 request key，只接受最后一次请求结果。
验证：新增并运行并发请求顺序测试，手工快速切换筛选没有再出现重复行。

vibe coding 的完成标准不是代码生成完，而是风险被关闭到当前阶段可以接受。

11. Owner 意识：AI 不负责，人负责

AI 需要人去规划、决策和 review。

即使现在很多人在用 AI 开发代码，团队里也必须有人做 owner。owner 不是职位，而是一种工作方式。

一个合格的 owner 至少要盯住六件事：

目标是否真的清楚，而不是只听起来合理；
任务是否已经拆到 AI 可以稳定执行的粒度；
风险是否及时暴露给团队，而不是藏在聊天记录里；
结果是否被验收，而不是只看 AI 的完成声明；
经验是否回流到文档、规则或 Skill；
从需求、实现、联调、测试、上线到反馈，是否有人持续看完整链路。

AI 可以帮你写代码、补文档、查 bug、跑测试、生成方案，但它不会为线上事故负责，也不会为需求误解负责，更不会为团队协作成本负责。

所以越是使用 AI，越要有 owner 意识。

AI 降低了执行成本，但没有降低责任成本。

12. 团队中怎么用 AI

个人用 AI 写 demo，可以随意一点；团队用 AI 写生产代码，必须严谨。

团队里需要统一几件事：

第一，统一公共规则。

哪些文件可以改，哪些命令必须跑，哪些安全边界不能碰，哪些代码风格必须遵守，这些应该写进 CLAUDE.md 或项目规则。

第二，统一任务颗粒度。

不要把“实现完整订单系统”丢给 AI。应该拆成：订单创建、库存锁定、支付回调、订单取消、超时关闭、退款、后台查询、测试覆盖。

第三，统一 review 标准。

AI 生成代码不能跳过 review。甚至更需要 review，因为它可能写出“看起来很合理但刚好错一点”的代码。

第四，统一验收方式。

每个模块完成时，都应该有可运行的测试、可点击的路径、可复现的验证方式或清晰的剩余风险说明。

第五，统一沉淀机制。

一次 AI 犯错不要只在聊天里纠正。重复出现的问题应该进入 CLAUDE.md、Skill、模板或 checklist。

团队用 AI 的关键不是每个人都变快，而是团队整体吞吐变高、返工变少、质量不下降。

13. 不同阶段应该给 AI 不同角色

不要让 AI 在所有任务里都扮演同一个“全能工程师”。不同阶段要给它不同角色。

原型阶段：

你是产品设计师和前端原型工程师，目标是快速生成可讨论的 UI，不追求最终架构。

方案阶段：

你是技术负责人，目标是把原型拆成可实现模块，指出风险和依赖，给出阶段计划。

后端阶段：

你是后端工程师，必须复用现有 service、route、schema 和测试工具，不允许发明新架构。

前端阶段：

你是前端工程师，必须匹配现有组件风格，覆盖加载态、空态、错误态和移动端布局。

联调阶段：

你是全栈联调工程师，目标是检查接口契约、字段命名、错误码、状态同步和真实用户路径。

AI 搭建阶段：

你是 AI 系统工程师，重点是 prompt、tool、memory、state machine、trace、eval、fallback 和人工确认边界。

测试阶段：

你是测试工程师，重点是复现路径、边界输入、回归风险、端到端闭环和最小验证命令。

Review 阶段：

你是严格的 code reviewer，只关注 bug、风险、回归和测试缺口，不做泛泛评价。

角色越清晰，AI 的输出越稳定。

14. 文档为什么排在高投入

AI 时代，文档不是“写给人看的附属品”，而是“写给人和 AI 共同使用的控制面”。

好的文档可以让 AI 更快进入项目上下文，减少错误假设。坏的文档会把 AI 带偏，而且偏得很自信。

项目里至少应该有几类文档：

产品需求文档：说明用户、目标、流程和非目标；
技术方案文档：说明模块、接口、数据、状态和依赖；
AI 规格文档：说明 prompt、tools、memory、eval、状态机和安全边界；
联调文档：说明接口契约、错误码、字段和测试账号；
测试文档：说明测试范围、命令、手工路径和已知风险；
运维文档：说明环境变量、部署、监控、告警和回滚。

文档不需要很长，但必须准确。尤其是给 AI 用的文档，要短、具体、结构化、可验证。

15. 测试会变得更重要

AI 写代码越快，测试越重要。

因为代码生成速度上来了，但理解速度、review 速度、联调速度没有同比提升。如果没有测试，团队会被大量“差一点正确”的代码淹没。

Stack Overflow 2025 Developer Survey 里，开发者对 AI 的主要挫败感之一就是“AI 给出的方案几乎正确但不完全正确”，另一个高频问题是调试 AI 生成代码更耗时。这和实际体感非常一致。

测试在 AI 开发里有两个作用。

第一，它是验收工具。

AI 说完成了不算，测试过了才接近完成。

第二，它是约束工具。

当你让 AI 修改代码时，已有测试会告诉它哪些行为不能破坏。没有测试的项目，AI 会更容易在无意中改变行为。

最实用的策略不是一开始追求 100% 覆盖率，而是优先覆盖：

核心用户路径；
权限和认证；
支付、订单、余额等资金相关逻辑；
AI tool 调用和状态流转；
数据写入和删除；
bug 修复的复现用例；
前后端接口契约；
高风险边界条件。

AI 生成代码的效率越高，测试就越像刹车和方向盘，而不是额外负担。

16. 前后端联调的核心问题

AI 可以很快生成前端，也可以很快生成后端，但它不一定能保证两边真的对上。

联调最常见的问题包括：

字段名不一致；
枚举值不一致；
错误码不一致；
空状态没处理；
分页协议不一致；
时间格式不一致；
权限失败时前端没有路径；
后端返回 nullable，前端按必填处理；
前端缓存导致状态不同步；
AI 生成 mock 后忘记接真实接口。

所以联调阶段要重点检查“契约”，不是只看代码。

一个简单有效的联调 prompt：

你是前后端联调工程师。

请检查当前功能的前端调用和后端接口是否一致。

重点检查：
- URL 和 method
- request body / query
- response 字段
- enum / status
- error format
- auth / permission
- loading / empty / error states
- mock 是否已替换为真实接口

输出：
- 不一致项
- 影响
- 推荐修复位置
- 最小验证方式

联调不是最后才做的事。每个小闭环都应该尽早联调。

17. 工程阶段怎么约束 AI

工程阶段要从“让 AI 发挥”切换成“让 AI 遵守”。

你应该给它明确边界：

不准改无关文件；
不准引入新依赖，除非说明理由；
不准发明数据库字段；
不准绕过现有权限；
不准跳过测试；
不准吞掉错误；
不准把 mock 当真实实现；
不准用大范围重构掩盖小问题；
不准在没有确认的情况下执行危险命令；
不准把敏感信息放进 prompt、日志或前端。

AI 不怕规则多，怕规则模糊。规则要短、硬、可检查。

最终结论

vibe coding 是一个机会，也是一种压力。

它让一个人可以更快做出原型，让小团队可以做过去需要更多人才能做的事情，也让非专业开发者有机会把想法变成软件。

但它不会自动带来高质量工程。AI 会放大人的能力，也会放大人的模糊、懒惰和侥幸。

所以真正值得追求的不是“让 AI 多写代码”，而是建立一套人和 AI 协作的工程系统：

用原型发现需求；
用文档收敛共识；
用提示词表达任务；
用 CLAUDE.md 固化公共规则；
用 Skill 复用经验；
用 SDD 约束复杂模块；
用小闭环降低风险；
用测试验证结果；
用 review 保持质量；
用 owner 意识承担责任。

vibe coding 的终点，不是不会写代码的人随便做软件。

它的终点应该是：会规划、会判断、会验收、会负责的人，借助 AI 更快地把正确的东西做出来。

前端流式输出实现：基于 Fetch API 的 SSE 实践

Sat, 03 Jan 2026 21:56:39 GMT

写在前面：流式输出就和它的名字一样，呈现一种水流形式一点一点进行输出。它是服务端对客户端的一种响应形式，这种输出使得响应数据可以一点点加载到页面上，避免用户等待很长时间，极大提高了用户体验。本文主要讲前端如何实现 SSE（Server-Sent Events）输出加载。

流式输出的概念

什么是流式输出?

流式输出就和它的名字一样，呈现一种水流形式一点一点进行输出。它是服务端对客户端的一种响应形式，这种输出使得响应数据可以一点点加载到页面上，避免用户等待很长时间，极大提高了用户体验。

图中所示就是一种典型的流式输出（用户和聊天机器人聊天的网络请求响应）： SSE 是单向输出，仅支持服务器向客户端发送消息。但在 AI 时代，用户通常需要向服务端传输复杂的 Body 信息数据（如 Prompt、上下文历史等），因此大多数现代流式输出方案都是基于 POST 形式的 HTTP 请求实现的。

为什么要有流式输出?

即时反馈：早期的大语言模型生成内容时是逐个 Token 产生的，如果等待内容全部生成才显示，用户需要忍受漫长的空白等待。
降低感知延迟：流式输出可以解决这个问题，显著减少用户感知的延迟，极大提高了用户的响应感官速度。

流式输出的实现

核心实现方案：Fetch API

对于这种不寻常的输出，前端应该怎么做? SSE 有它自己独特的响应接收形式，我们需要使用最底层的请求方式来实现它。我们通过 Fetch API 来实现。

EventSource 的局限性：原生 EventSource 只支持 GET 请求，无法在 Body 中发送 JSON 数据，且不支持自定义 Headers（如 Authorization），这在现代鉴权系统中是致命的。
Fetch 的优势：Fetch 支持 POST，支持自定义 Headers，且通过 response.body.getReader() 可以实现与 SSE 完全一致的流式读取。

实现步骤详解

第一步: 建立连接 流式输出虽然是获取数据，但由于需要携带复杂的 Data，通常使用 POST 方法并配置相应的请求头。

第二步: 使用 Streams API 实现流式读取 传统的 API 是等待整个 Response 下载完成，但使用 Stream 可以实现：后端生成一个字，前端收到一个字。内存占用极低，且用户能立即看到反馈。

const reader = response.body.getReader();
const { done, value } = await reader.read();

RAG

Sat, 03 Jan 2026 21:56:39 GMT

最近 AI 模型逐渐火热，作为一名程序员当然要追寻时代的潮流，学习了部分 AI 知识，其中 RAG 和 Agent 都比较出名。趁着这个时间，我来简单讲解一下 RAG，后续可能还会继续学习并分享这部分内容。

`什么是 RAG？`

RAG 全称 Retrieval-Augmented Generation，也就是 检索增强生成。

简单来说，RAG 就是给大模型配了一个 外挂知识库。模型自己不知道的东西，先去知识库里面翻一翻，找到相关的资料，然后再基于这些资料来回答你的问题。

我们都知道 LLM（大语言模型）是有局限的，它的底层是 Transformer 架构，本质上是一个”文字接龙”游戏 —— 根据前面的文字预测后面最可能出现的文字。这就导致一个问题：当模型遇到自己不懂的东西时，它不会说”我不知道”，而是会一本正经地胡说八道，也就是所谓的”幻觉”。

RAG 的诞生就很好地解决了这个问题。它的核心思路特别朴素：你不是容易编？那我先帮你把答案找好，你照着答案说就行了。

打个比方：

没有 RAG 的大模型 = 闭卷考试，全靠记忆力，记不住就瞎编
有 RAG 的大模型 = 开卷考试，可以翻书找答案，准确率大幅提升

`RAG 可以解决什么问题？`

1. 幻觉问题

大模型最大的痛点就是幻觉 —— 对用户的回答胡编乱造，而且编得特别像那么回事，让你真假难辨。

比如你问它”某某公司 2024 年的营收是多少”，它可能会非常自信地给你一个数字，但这个数字完全是它编的。有了 RAG 之后，模型会先去知识库里找这家公司的财报数据，基于真实数据回答，准确性大幅提升。

2. 知识过时

模型训练完成之后，它所知道的东西都是当时训练时候接触到的信息，并不会自动进化。比如一个 2023 年训练的模型，你问它 2024 年发生了什么，它是真的不知道。

RAG 的知识库可以随时更新。你只需要把最新的文档扔进知识库，模型就能”学到”最新的知识，不需要重新训练。

3. 没有私有数据

这是企业场景中最核心的需求。你公司的内部文档、技术手册、客户资料，这些东西不可能出现在大模型的训练数据中。通过知识库，我们可以搭建一个自己的私人模型，给公司或者团队进行使用。

举个例子：你把公司的员工手册放进知识库，新员工就可以直接问 AI”年假有多少天”、“报销流程是什么”，AI 会基于员工手册给出准确的回答。

4. 答案溯源

对于一些严肃的问答场景（法律、医疗、金融），必须要能追溯答案来源。RAG 可以在回答中标注”这段话来自哪个文档的哪一页”，让用户自己去核实。这样就避免了模型瞎编造成严重的后果。

比如回答法律问题时引用具体的法条，回答医疗问题时引用临床指南，这些引用都是可以追溯验证的。

`RAG 和微调有什么区别？`

你可能会问：要让模型学会新知识，直接微调不行吗？为什么还要搞 RAG？

这两个方案各有优劣，简单对比一下：

维度	RAG（检索增强）	微调（Fine-tuning）
成本	低，只需要搭建检索系统	高，需要 GPU 训练
更新知识	往知识库加文档就行，分钟级	需要重新训练，小时到天级
准确性	高，基于原文回答	可能产生幻觉
答案溯源	支持，能标注引用来源	不支持
适用场景	知识密集型问答	调整模型的风格和行为
数据隐私	数据在自己的库里，可控	数据需要参与训练

一句话总结：RAG 是给模型"查资料"，微调是给模型"补课"。大多数企业场景下，RAG 是更实用的选择。

`RAG 的核心概念`

在讲工作原理之前，先搞清楚几个核心概念，不然后面可能看不懂。

Embedding（向量嵌入）

这是 RAG 里面最重要的概念。

我们人类理解文字靠语义，但计算机只认数字。Embedding 就是把一段文字变成一组数字（向量），而且意思相近的文字，变成的数字也相近。

比如：

“苹果手机” → [0.2, 0.8, 0.1, 0.5, …]
“iPhone” → [0.21, 0.79, 0.12, 0.48, …]
“今天天气不错” → [0.9, 0.1, 0.7, 0.3, …]

你会发现”苹果手机”和”iPhone”的向量非常接近，但跟”今天天气不错”差得很远。这就是 Embedding 的魔力 —— 它把语义相似性转化成了数学上的距离问题。

向量数据库

有了向量，总得有地方存吧？向量数据库就是专门存储和检索向量的数据库。

普通数据库的查询是”帮我找 name = ‘张三’ 的记录”，向量数据库的查询是”帮我找和这个向量最相似的 Top 10 个向量”。

相似度计算

怎么衡量两个向量”像不像”？主要有两种方法：

余弦相似度：计算两个向量之间的夹角。夹角越小，越相似。值域是 -1 到 1，1 表示完全相同。这是最常用的方法。

欧氏距离：计算两个向量之间的直线距离。距离越小，越相似。

大多数 RAG 系统用的是余弦相似度。

分块（Chunking）

一篇文档可能有几万字，但用户的问题通常只对应其中一小段。如果把整篇文档丢给模型，既浪费 token，又可能干扰模型找到重点。

所以我们需要把文档切成小块，每块存一个向量。检索的时候只返回最相关的几个小块，而不是整篇文档。

切块看起来简单，实际上很有讲究：切太大，检索不精准；切太小，语义不完整。一般每块 100-500 个 token 比较合适。

`RAG 的工作原理`

RAG 的工作原理主要分为三步，我们一步一步来看。

第一步：处理文档（离线阶段）

上传文档 → 解析文档 → 文本分块 → 向量化 → 向量存储

这一步是在用户提问之前就完成的，属于”备货”阶段。

上传文档

用户把文档（PDF、Word、Excel、Markdown 等）上传到系统。

解析文档

不同格式的文档，解析方式完全不同：

PDF：这是最复杂的。PDF 本质上是一种”画图指令”，它告诉渲染器在哪个坐标画什么字，并不像 Word 那样有明确的段落结构。所以 PDF 解析需要做版面分析 —— 用 AI 模型识别页面上哪些是标题、哪些是正文、哪些是表格、哪些是图片。对于扫描件类型的 PDF，还需要 OCR（光学字符识别）把图片中的文字识别出来。
Word：结构相对清晰，可以直接提取段落、标题、表格等。
Excel：按行或按表格提取，通常转成文字描述。
Markdown/TXT：最简单，直接按段落分割。

解析质量直接决定了后续所有环节的上限。这个阶段如果把文字弄错了、把表格弄乱了，后面检索再准也没用。所以业界有一句话：RAG 的第一道坎是解析。

文本分块

解析出来的文本需要切成小块。主要有三种分块策略：

固定大小分块：按固定的 token 数（比如每 128 个 token）切一刀。优点是简单，缺点是可能把一句话从中间切断。

基于分隔符分块：按句号、换行符、章节标题等自然边界切分。比固定大小更合理，但可能导致块大小不均匀。

语义分块：用 Embedding 模型计算相邻句子的语义相似度，在相似度突然下降的位置切分。理论上最优，但计算成本高。

实际项目中，通常是把这些策略混合使用 —— 先按自然段落分割，再按 token 数合并或拆分，确保每个块既有完整语义又不会太长。

向量化

把每个文本块送进 Embedding 模型，得到一个高维向量（比如 1024 维的浮点数数组）。

这一步的关键是选对模型。Embedding 模型的质量直接决定了”语义相似的内容能不能被检索到”。如果模型觉得”盈利增长”和”利润提升”不像，那检索就废了。

向量存储

把文本块的原文和对应的向量一起存入向量数据库（或带向量能力的搜索引擎）。每条记录大概长这样：

{
  "id": "chunk_001",
  "content": "公司2023年营收达到50亿元，同比增长15%...",
  "vector": [0.12, 0.34, 0.56, ...],    // 1024维向量
  "metadata": {
    "source": "年报.pdf",
    "page": 5
  }
}

到这里，“备货”就完成了。知识库已经准备好了，等待用户来提问。

第二步：查询检索（在线阶段）

用户查询 → 查询向量化 → 相似度检索 → 结果重排 → 上下文组装

用户查询

用户输入一个问题，比如”公司去年的营收增长了多少？“

查询向量化

把用户的问题用同一个 Embedding 模型转成向量。这里有一个关键点：查询和文档必须用同一个模型，否则它们的向量在不同的空间里，无法比较相似度。

相似度检索

拿着查询向量去向量数据库里找最相似的文本块。

这一步有两种主流策略：

纯向量检索：只比较向量的余弦相似度。优点是能理解语义（“营收”和”收入”能匹配上），缺点是对具体的数字、人名等精确信息不敏感。

混合检索（推荐）：向量检索 + 关键词检索同时进行，然后把两者的结果融合。这样既能匹配语义，又能精确匹配关键词，两全其美。

举个例子：用户问”2023 年 Q3 营收”

向量检索能匹配到”第三季度收入”（语义相似）
关键词检索能精确匹配到含有”2023”和”Q3”的文本块
两者结合，效果最好

结果重排（Rerank）

检索返回的结果可能有几十条，但质量参差不齐。重排（Rerank）就是对这些初步结果做精细化排序，把最相关的排到前面。

简单理解，检索是”海选”，重排是”决赛”。

重排模型（Cross-Encoder）比普通的 Embedding 模型（Bi-Encoder）更精确，因为它会把查询和文档拼在一起一起看，能更好地理解两者之间的关系。但代价是速度慢，所以只能对少量候选做重排，不能对全量数据做。

这就形成了经典的 漏斗架构：

全量文档 → 粗排（向量检索，快但粗）→ 精排（Rerank模型，慢但精）→ Top-K 结果

上下文组装

把排序后的 Top-K 个文本块（通常 3-5 个）组装成”参考资料”，准备塞进提示词里。

第三步：增强生成

构建提示词 → 大语言模型 → 最终答案

构建提示词

把用户的问题和检索到的参考资料按照一定的模板组装成提示词。一个典型的提示词长这样：

你是一个专业的助手，请基于以下参考资料回答用户的问题。
如果参考资料中没有相关信息，请诚实地说"我不知道"。

参考资料：
[1] 公司2023年营收达到50亿元，同比增长15%...
[2] 第三季度单季营收18亿元，创历史新高...
[3] 公司预计2024年营收目标为60亿元...

用户问题：公司去年的营收增长了多少？

请基于以上参考资料回答。

提示词设计有几个要点：

明确角色：告诉模型它是什么身份
给出规则：特别是”不知道就说不知道”这条，防止幻觉
标注来源：要求模型在回答中引用参考资料的编号，方便溯源
参考资料在前，问题在后：这样模型先”看”完资料再思考问题

大语言模型生成

提示词发送给 LLM，模型基于参考资料生成回答。由于参考资料是真实的文档内容，模型的回答会更加准确、更有依据。

最终答案

模型返回的回答可能长这样：

根据参考资料，公司 2023 年营收达到 50 亿元，同比增长了 15% [1]。其中第三季度单季营收 18 亿元，创下历史新高 [2]。

方括号里的数字就是引用标注，用户可以点击查看对应的原文，验证答案是否准确。

`RAG 常见的坑`

坑 1：分块太大或太小

分块太大（比如一整页），检索出来一大段文字，真正有用的可能就一两句，大量无关信息会干扰模型判断。分块太小（比如一两句话），语义不完整，模型理解不了上下文。

建议：从 128-256 个 token 开始尝试，根据实际效果调整。

坑 2：解析质量差

特别是 PDF 文档。很多 PDF 看起来排版整齐，但内部结构混乱 —— 多栏排版、表格嵌套、扫描件等情况，简单的文本提取工具根本处理不好。如果解析出来的文本顺序是乱的、表格变成了一堆散乱的数字，后面再怎么优化也是白搭。

建议：选用专业的 PDF 解析方案（比如 DeepDoc、Unstructured），而不是简单的 PyPDF2。

坑 3：没有做重排序

只靠向量检索的初步结果就直接用，精度通常不够。加一个 Rerank 模型做精排，往往能显著提升效果，是性价比很高的优化手段。

坑 4：提示词设计不当

最常见的错误是没有告诉模型”不知道就说不知道”。模型会默认尽力回答，即使参考资料里没有相关信息也会编造。明确的指令约束非常重要。

坑 5：Embedding 模型不匹配

用英文 Embedding 模型处理中文文档，或者查询和文档用了不同的 Embedding 模型，都会导致检索效果大幅下降。

建议：中文场景选中文或多语言模型，查询和文档必须用同一个模型。

总结

RAG 的核心思想其实非常简单：先帮模型找到答案，再让模型组织语言。

它不是什么高深莫测的黑科技，而是一个非常工程化的解决方案。每一步（解析、分块、向量化、检索、重排、生成）都有成熟的工具和方案可以选用。

对于程序员来说，RAG 是一个值得深入学习的方向。它不需要你有深度学习的理论基础（那是训练模型的人需要的），更多的是 系统设计和工程优化 能力 —— 怎么解析文档更准确、怎么分块更合理、怎么检索更精准、怎么提示词更有效。

如果你想动手实践，推荐的技术栈：

文档解析：DeepDoc / Unstructured / LlamaParse
Embedding 模型：text-embedding-v3（阿里云） / BGE（开源）
向量存储：Elasticsearch / Milvus / Chroma
LLM：DeepSeek / Qwen / GPT-4
框架：LangChain / LlamaIndex / RAGFlow

为什么我们不能直接双击打开 HTML？

Sun, 30 Nov 2025 18:04:54 GMT

现象描述

当我们刚开始学习 HTML 时，最直观的操作就是在文件夹中直接双击 index.html。这时浏览器地址栏显示的是：

file:///C:/Users/YourName/Project/index.html

虽然页面能打开，但经常遇到莫名其妙的 Bug：

❌ 图片显示不出来（尤其是使用了 / 开头的绝对路径时）。
❌ AJAX 请求直接报错（CORS 错误）。
❌ ES6 模块 (import/export) 无法运行。

而当我们使用 VS Code 的 Live Server 插件，或者前端框架的 npm run dev 后，浏览器自动弹出的地址是：

http://127.0.0.1:5500/index.html

神奇的是，这时候一切都正常了。这背后的根本原因，在于协议的不同。

深度解析：file:// 协议 (本地文件模式)

当你双击文件时，浏览器使用的是 file:// 协议。在这个模式下，浏览器把你当作一个文件查看器，而不是一个网页浏览器。为了保护你的电脑安全，浏览器实施了极其严格的“沙箱限制”。

限制一：路径解析逻辑不同 (图片为何加载失败？)

这是新手最容易踩的坑。如果你的代码写的是绝对路径：

<img src="/logo.png" />

在 file:// 模式下： 浏览器看到的“根”是你电脑的文件系统根目录（Windows 的 C 盘）。浏览器会尝试去访问：file:///C:/logo.png。
结果： 你的 C 盘根目录下显然没有这张图，所以图片加载失败。

限制二：安全策略不允许网络请求

原因： 浏览器的同源策略。
现象： 浏览器禁止 JS 通过 fetch 或 XMLHttpRequest 去读取本地文件。
为什么： 试想一下，如果随便下载一个网页保存到本地，双击打开后，它就能读取你硬盘里的 C:/Passwords.txt 并发送给黑客，那太可怕了。所以浏览器直接禁用了这种能力。

限制三：现代模块化无法使用

如果你使用了 <script type="module"> (ES Modules)，在 file:// 下会直接报错。因为浏览器认为让一个本地文件去“加载”另一个本地脚本是不安全的。

深度解析：http:// 协议 (Live Server 模式)

当你启动 Live Server 时，你实际上是在本地电脑上搭建了一个小型的 Web 服务器。浏览器通过 http:// 协议与这个服务器通信，这才是标准的“网页浏览”环境。

优势一：正确的“根目录”映射

原理： Live Server 会把你当前的项目文件夹，映射为服务器的网站根目录 (Web Root)。
结果： 当你请求 <img src="/logo.png"> 时，浏览器向服务器请求“网站根目录下的 logo.png”。服务器会去你的项目文件夹里找 logo.png 并返回。
结论： 图片成功加载。

优势二：正常的网络权限

在 http:// 环境下，浏览器认为这是一个正常的网站。只要遵守同源策略，你的 fetch 请求、import 模块化语法都可以正常工作。这完全模拟了代码上线后的真实运行环境。

总结对比表

特性	file:// (双击打开)	http:// (Live Server)
根目录 (/) 指向	电脑磁盘根目录 (如 C:)	你的项目文件夹
AJAX / Fetch	被浏览器拦截 (CORS)	正常工作
ES Modules	无法加载	正常加载
适用场景	仅用于查看纯文本/简单 Demo	必须用于正式开发

思考：为什么要有这种区分？

这并不是浏览器的 Bug，而是有意为之的安全特性。

file:// 协议的设计初衷是让你查看本地文件（比如打开一个 PDF，看一张本地照片），而不是让你运行一个复杂的 Web 应用。一旦涉及到资源引用、数据交互或模块化，我们就必须建立一个符合 Web 标准看齐的服务器环境（即 http://），这不仅是为了功能正常，更是为了模拟真实的用户访问场景。

Vue的响应式原理

Wed, 05 Nov 2025 17:30:00 GMT

想必大家在学习 Vue 的时候都会有这样的疑问：在学习原生 JavaScript 时，不论修改什么内容，通常只有在页面刷新时值才会更新。但在 Vue 项目中，数据变化却能实现页面的实时更新。这就是 Vue 的核心特性——响应式数据更新。

Vue 2 响应式原理

核心实现：Object.defineProperty()

Vue 2 通过 Object.defineProperty() 来实现响应式。当你创建一个 Vue 实例并将数据添加到 data 选项中时，Vue 会遍历这些数据，并使用 Object.defineProperty() 为每个属性添加 getter 和 setter。

Getter: 用于追踪依赖（依赖收集）。
Setter: 用于在属性被修改时通知变更。

中枢神经：Watcher

Watcher 是 Vue 2 响应式系统的核心，扮演着中枢神经的角色，承担三大核心职责：

收集依赖：记录哪些组件用到了这个数据。
变更检测：感知数据的变化。
更新调度：通知视图进行重新渲染。

局限性：无法检测数组和对象的新增

Vue 2 不能检测到通过索引直接修改数组或动态添加对象属性的变化。

原因：索引赋值不会触发 setter 函数。
解决方案：Vue 2 重写了数组的 7 个方法（push, pop, shift, unshift, splice, sort, reverse）来手动触发响应式更新。

示例代码对比

<div id="app">
  <ul>
    <li v-for="(item, index) in list" :key="index">{{ item }}</li>
  </ul>
  <button @click="updateByIndex">直接索引修改（无效）</button>
  <button @click="updateBySplice">用 splice 修改（有效）</button>
</div>

<script>
  new Vue({
    el: "#app",
    data: {
      list: [1, 2, 3],
    },
    methods: {
      // 直接使用索引赋值：页面不会更新
      updateByIndex() {
        this.list[0] = 4;
        console.log("数组已变但页面未更新：", this.list);
      },
      // 使用 splice 方法：页面实时更新
      updateBySplice() {
        this.list.splice(0, 1, 4);
        console.log("页面同步更新：", this.list);
      },
    },
  });
</script>

Vue 3 响应式原理

核心实现：Proxy

Vue 3 改用 ES6 的 Proxy 特性来实现响应式对象。Proxy 可以直接代理整个对象，而不是像 defineProperty 那样只能代理属性。

ref 与 reactive 的区别

reactive: 只能用于数组和对象类型。它底层完全基于 Proxy 实现。
ref: 可以用于所有类型。
如果封装的是简单类型（如 String, Number），Vue 3 会回退使用 getter/setter（.value 访问），因为对简单类型使用 Proxy 性能开销反而更大。
如果封装的是复杂类型，ref 内部依然会调用 reactive（即 Proxy）。

核心机制：track 与 trigger

track: 依赖收集函数。在 get 阶段运行，记录当前是哪个副作用函数（Effect）在访问数据。
trigger: 依赖触发函数。在 set 阶段运行，当数据变化时，通知所有收集到的依赖重新执行。

Vue 3 简化版原理实现

const targetMap = new WeakMap(); // 存储对象的所有依赖
let activeEffect = null; // 当前正在运行的副作用函数

// 依赖收集
function track(target, key) {
  if (activeEffect) {
    let depsMap = targetMap.get(target);
    if (!depsMap) targetMap.set(target, (depsMap = new Map()));
    let dep = depsMap.get(key);
    if (!dep) depsMap.set(key, (dep = new Set()));
    dep.add(activeEffect);
  }
}

// 触发更新
function trigger(target, key) {
  const depsMap = targetMap.get(target);
  if (depsMap) {
    const dep = depsMap.get(key);
    if (dep) dep.forEach((effect) => effect());
  }
}

// 创建响应式对象
function reactive(target) {
  return new Proxy(target, {
    get(target, key, receiver) {
      track(target, key);
      const res = Reflect.get(target, key, receiver);
      return typeof res === "object" && res !== null ? reactive(res) : res;
    },
    set(target, key, value, receiver) {
      const oldValue = target[key];
      const result = Reflect.set(target, key, value, receiver);
      if (oldValue !== value) trigger(target, key);
      return result;
    },
  });
}

Vue 2 vs Vue 3 核心区别汇总

特性	Vue 2	Vue 3	核心差异说明
实现原理	`Object.defineProperty`	`Proxy`	Proxy 直接代理整个对象，无需递归初始化属性。
数组响应式	需重写数组方法	原生支持	Vue 3 可直接通过索引 `arr[0]=1` 或修改 `length` 触发更新。
动态新增属性	需用 `Vue.set()`	直接赋值生效	Vue 3 中 `obj.newProp = value` 自动触发响应式。
初始化性能	递归遍历所有属性	按需惰性代理	Vue 3 极大减少了大型对象的初始化开销。
集合支持	不支持	支持 Map/Set 等	Vue 3 原生支持 `Map`, `Set`, `WeakMap` 的响应式。
API 灵活性	仅限于 `data` 选项	`ref` / `reactive`	Vue 3 的响应式 API 可脱离组件单独使用。
调试能力	较弱	增强的调试钩子	提供 `onTrack` 和 `onTrigger` 钩子，方便追踪变化。

总结：Vue 3 通过 Proxy 解决了 Vue 2 中最令人头疼的数组/对象新增属性不响应的问题，并通过惰性代理和精简的依赖追踪机制，带来了更强劲的性能表现。

JavaScript 垃圾回收机制

Wed, 05 Nov 2025 10:44:20 GMT

垃圾回收的概念

什么是垃圾回收机制

GC 即 Garbage Collection ，程序工作过程中会产生很多”垃圾”，这些垃圾是程序不用的内存或者是之前用过了，以后不会再用的内存空间，而 GC 就是负责回收垃圾的，因为他工作在引擎内部，所以对于我们前端来说，GC 过程是相对比较无感的，这一套引擎执行而对我们又相对无感的操作也就是常说的 垃圾回收机制 不是所有语言都有 GC，一般的高级语言里面会自带 GC，比如 Java、Python、JavaScript 等，也有无 GC 的语言，比如 C、C++ 等，那这种就需要我们程序员手动管理内存了，相对比较麻烦在像 C/C++ 这样的语言中，开发者需要手动分配（malloc）和释放（free）内存。这种方式非常灵活，性能也高，但有两个致命缺点：

忘记释放：会导致内存泄漏，程序占用的内存会随着时间推移越来越多，最终可能导致程序崩溃或系统变慢。
提前释放：或释放了多次，会导致悬挂指针，当程序尝试访问一个已经被释放的内存地址时，会引发不可预知的错误（通常是程序崩溃）。

JavaScript 中存在两种变量：局部变量和全局变量。全局变量的生命周期会持续到页面卸载；而局部变量声明在函数中，它的生命周期从函数执行开始，直到函数执行结束，在这个过程中，局部变量会在堆或栈中存储它们的值，当函数执行结束后，这些局部变量不再被使用，它们所占有的空间就会被释放。（不过，当局部变量被外部函数使用时，其中一种情况就是闭包，在函数执行结束后，函数外部的变量依然指向函数内部的局部变量，此时局部变量依然在被使用，所以不会回收。）

垃圾回收的实现

核心理念

GC 机制的核心思想是可达性。简单来说，就是判断一个对象是否“可达”，如果不可达，它就是“垃圾”。

可达的对象：以某种方式被访问或使用的对象。
不可达的对象：无法被访问到的对象，可以被安全地回收。

GC 会有一系列的根对象，它们是可达性的起点。在 JavaScript 中，主要的根包括：

全局对象：比如浏览器环境下的 window 对象，Node.js 环境下的 global 对象。 因为全局对象在应用程序的整个生命周期内都存在。只要你的网页开着，window 对象就永远不会消失。它是所有全局变量和内置 API（如 setTimeout, localStorage）的宿主。如果它被回收了，整个 JavaScript 环境就都将崩塌。因此，全局对象是 GC 最重要、最基础的一个“根”。

函数调用栈：当前正在执行的函数中的局部变量和参数。 因为当前正在执行的代码和它所依赖的数据，理所当然是“存活”的。调用栈代表了程序执行的“此时此刻”。如果这些正在使用的变量被回收了，程序将立即出错。因此，调用栈中所有栈帧里的变量和参数，都被视为临时的“根”。

活跃的 DOM 树：页面上存在的 DOM 元素。 因为 DOM 节点是构成用户界面的实体。用户能看到、能与之交互的元素，必须始终存在于内存中，浏览器需要依据它来进行绘制和响应事件。因此，所有在 DOM 树上的节点都被认为是“可达的”。

垃圾回收器会从这些“根”出发，沿着引用链进行遍历。所有能从“根”访问到的对象，都会被认为是“活”的（可达的）；反之，所有无法从“根”访问到的对象，就会被认为是“死”的（不可达的），并成为垃圾回收的目标。

// 创建一个根对象，并被变量 user 引用
let user = {
  name: "Alice"
};

// 原来的 { name: "Alice" } 对象失去了引用，因此它变成了不可达对象，等待被回收。
user = null;

主流垃圾回收算法

浏览器通常使用的垃圾回收方法有两种：标记清除，引用计数。

标记清除 这是现代浏览器中最常用的垃圾回收算法。它完美地解决了循环引用的问题。

原理：分为两个阶段：
1. 标记阶段：垃圾回收器从“根”对象开始，遍历所有可达的对象，并在这些对象上打上一个“标记”，表示它们是存活的。
2. 清除阶段：垃圾回收器遍历整个堆内存，所有没有被标记的对象都被视为垃圾，并被回收，其占用的内存被释放。
优点：可以解决循环引用的问题。因为即使 objA 和 objB 互相引用，但如果它们都无法从“根”访问到，那么它们就都不会被标记，最终会被一起清除。

function createCircularReference() {
  let objA = {};
  let objB = {};

  objA.b = objB; 
  objB.a = objA; 
}

createCircularReference();

缺点：
- 执行效率问题：GC 执行时，需要暂停整个程序的运行，如果堆内存很大，标记和清除会很耗时。
- 内存碎片化：清除后，会产生大量不连续的内存碎片。如果之后需要分配一个大对象，可能会因为没有足够大的连续空间而失败。

引用计数 这是早期的一种 GC 算法，思想非常简单。

原理：为每个对象维护一个“引用计数器”。当有一个引用指向该对象时，计数器加 1；当引用被移除时，计数器减 1。当计数器变为 0 时，表示该对象不再被需要，可以被回收。
优点：实现简单，垃圾可以被立即回收，不会有“暂停”的感觉。
致命缺点：无法处理循环引用。看下面的例子：

这种情况下，就要手动释放变量占用的内存：

obj1.a =  null
obj2.a =  null

V8 引擎的优化：分代回收

为了解决标记-清除算法的效率问题，Google 的 V8 引擎（用于 Chrome 和 Node.js）采用了一种更先进的策略：分代回收。这个策略基于一个重要的观察：“大部分对象都是朝生夕死的”。也就是说，很多对象在创建后很快就不再被使用，而少数对象会存活很长时间。

V8 将堆内存分为两个主要区域： 新生代：Scavenge 算法

特点：存放生命周期短的对象，空间较小（通常为 1-8MB），垃圾回收频繁且速度快。
内部结构：新生代内存被平分为两个相等的空间：From 空间（使用中） 和 To 空间（空闲）。
回收过程：
1. 新对象首先被分配在 From 空间。
2. 当 From 空间快要被占满时，触发一次新生代的 GC。
3. GC 会检查 From 空间中的存活对象，并将它们复制到 To 空间。
4. 复制完成后，From 空间剩下的所有对象都是垃圾。整个 From 空间被一次性清空。
5. From 空间和 To 空间的角色互换，等待下一次 GC。
晋升：如果一个对象在新生代中经过了多次 Scavenge 依然存活，那么它被认为是生命周期较长的对象，会被“晋升”到老生代中。此外，如果复制一个对象到 To 空间时，To 空间的使用率超过了 25%，该对象也会被直接晋升到老生代。 老生代：标记-清除与标记-整理
特点：存放生命周期长或体积大的对象，空间较大，GC频率较低。
回收过程：
1. 主要使用标记-清除算法，流程如前所述。
2. 为了解决内存碎片化问题，V8 引入了标记-整理算法。它在标记阶段之后，不是直接清除垃圾，而是将所有存活的对象向内存的一端移动，然后直接清理掉边界之外的所有内存。这样就得到了连续的空闲空间。

减少垃圾回收

手动处理

虽然浏览器可以进行垃圾自动回收，但是当代码比较复杂时，垃圾回收所带来的代价比较大，所以应该尽量减少垃圾回收。

对数组进行优化： 在清空一个数组时，最简单的方法就是给其赋值为[ ]，但是与此同时会创建一个新的空对象，可以将数组的长度设置为 0，以此来达到清空数组的目的。
对对象进行优化： 对象尽量复用，对于不再使用的对象，就将其设置为 null，尽快被回收。

避免意外的全局变量：始终使用 const 或 let 声明变量，开启严格模式（'use strict';）。

function leakyFunction() {
  // 如果没有 'let' 或 'const', a 会被创建为全局变量
  // 它将永远不会被回收，除非手动设为 null
  a = new BigObject();
}

警惕闭包： 闭包是 JavaScript 的强大特性，但也很容易造成内存泄漏。闭包可以使其父函数中的变量在函数执行结束后仍然存活。

function createClosure() {
  let largeData = new Array(1e6).fill('*'); 

  // 这个返回的函数持有了对 largeData 的引用
  return function() {
  	...
    return largeData.length;
  };
}

let myClosure = createClosure();
// 即使 createClosure 执行完毕，largeData 也不会被回收，因为它被 myClosure 引用。
// 如果不再需要它，应手动解除引用。
myClosure = null;

定时器和事件监听器： setInterval, setTimeout 和 addEventListener 如果不被正确清理，它们的回调函数和其引用的外部变量都不会被回收。

let element = document.getElementById('my-button');
let largeData = new BigObject();

function onClick() {
  // do something with largeData
}

element.addEventListener('click', onClick);

// 正确做法：
// element.removeEventListener('click', onClick);
// element = null;

在组件销毁或元素移除时，务必使用 clearInterval, clearTimeout 和 removeEventListener 清理掉相关的定时器和监听器。

JavaScript 继承详讲

Wed, 05 Nov 2025 10:44:20 GMT

在 JavaScript 中，继承是非常核心重要的，今天我要和大家分享一下 JavaScript 中的继承都有那些，以及对应的一些优缺点。

原型链继承

原型链继承是 JavaScript 中实现继承的一种基本方式，它利用原型机制让一个对象能够访问另一个对象的属性和方法。

原型链継承的核心思想是：将父类的实例作为子类的原型对象，这样，子类实例就可以通过原型链访问父类的属性和方法

示例:

function Animal(name) {
    this.name = name || 'Animal';
    this.colors = ['red', 'blue'];
}

Animal.prototype.sayName = function() {
    console.log('My name is ' + this.name);
};

function Cat() {
    this.type = 'cat';
}

Cat.prototype = new Animal();
Cat.prototype.constructor = Cat;

Cat.prototype.meow = function() {
    console.log('Meow!');

const cat1 = new Cat();
cat1.sayName();
cat1.meow();

为什么constructor要进行修复：

const cat = new Cat();
console.log(cat.constructor === Animal); // true - 错误！
console.log(cat.constructor === Cat); // false - 不正确

原型链结构分析

cat1 (Cat 实例) ├── 自身属性: type = ‘cat’ └── proto → Cat.prototype (Animal 实例) ├── constructor: Cat ├── meow: function └── proto → Animal.prototype ├── constructor: Animal ├── sayName: function └── proto → Object.prototype

原型链继承的特点

优点

实现简单：代码简洁，易于理解
纯粹的继承关系：子类是父类的实例，也是父类的子类的实例
方法复用：父类方法可以被所有子类实例共享

缺点

引用类型属性共享问题

const cat1 = new Cat();
const cat2 = new Cat();

cat1.colors.push("green");
console.log(cat2.colors); // ['red', 'blue', 'green'] - 被影响了！

无法向父类构造函数传参

// 无法在创建Cat实例时给Animal传参
const cat = new Cat("Tom"); // 这里的参数无法传递给Animal

无法实现多继承

Child.prototype = new Parent1();
// 无法同时设置：Child.prototype = new Parent2();

验证继承关系的方法 :

const cat = new Cat();

console.log(cat instanceof Cat); // true
console.log(cat instanceof Animal); // true
console.log(cat instanceof Object); // true

console.log(Cat.prototype.isPrototypeOf(cat)); // true
console.log(Animal.prototype.isPrototypeOf(cat)); // true

构造函数继承

构造函数继承（Constructor Inheritance）是 JavaScript 中实现继承的重要方式之一，它通过在子类构造函数中调用父类构造函数来实现继承。

在子类构造函数中，使用call()或apply()方法调用父类构造函数，将父类的属性和方法绑定到子类实例上：

function Child() {
  Parent.call(this); // 关键步骤
  // 子类自己的属性初始化
}

示例

function Animal(name) {
  this.name = name || "Animal";
  this.colors = ["red", "blue"];
  this.sayName = function () {
    console.log("My name is " + this.name);
  };
}

function Cat(name) {
  // 调用父类构造函数，继承属性
  Animal.call(this, name);
  this.type = "cat";
  this.meow = function () {
    console.log("Meow!");
  };
}

const cat1 = new Cat("Tom");
cat1.sayName();
cat1.meow();

构造函数继承的特点

优点

解决引用类型共享问题

const cat1 = new Cat("Tom");
const cat2 = new Cat("Jerry");

cat1.colors.push("green");
console.log(cat1.colors); // ['red', 'blue', 'green']
console.log(cat2.colors); // ['red', 'blue'] - 互不影响

支持向父类传递参数

function Cat(name) {
  Animal.call(this, name); // 传递name参数
  // ...
}

可实现多继承

function FlyingAnimal() {
  this.canFly = true;
  this.fly = function () {
    console.log("Flying!");
  };
}

function Cat(name) {
  Animal.call(this, name);
  FlyingAnimal.call(this); // 多继承
  // ...
}

缺点

无法继承父类原型上的方法

// 将方法定义在原型上
Animal.prototype.sayName = function () {
  console.log("My name is " + this.name);
};

const cat = new Cat("Tom");
cat.sayName(); // TypeError: cat.sayName is not a function

方法无法复用

每个实例都会创建自己的方法副本：

const cat1 = new Cat();
const cat2 = new Cat();
console.log(cat1.sayName === cat2.sayName); // false

无法使用 instanceof 检查继承关系

console.log(cat1 instanceof Animal); // false

组合继承

组合继承（Combination Inheritance）是 JavaScript 中最常用的继承模式，它结合了原型链继承和构造函数继承的优点，同时规避了它们的缺点。

核心概念

组合继承的核心思想是：

使用构造函数继承来继承父类的实例属性
使用原型链继承来继承父类的原型方法

实现步骤

function Animal(name) {
  this.name = name || "Animal";
  this.colors = ["red", "blue"];
}
Animal.prototype.sayName = function () {
  console.log("My name is " + this.name);
};

function Cat(name, age) {
  Animal.call(this, name);
  this.age = age || 1;
  this.type = "cat";
}

Cat.prototype = new Animal();
// 7. 修复constructor指向
Cat.prototype.constructor = Cat;
Cat.prototype.meow = function () {
  console.log("Meow! I am " + this.age + " years old.");
};

组合继承的优势

解决引用类型共享问题

const cat1 = new Cat("Tom", 2);
const cat2 = new Cat("Jerry", 1);

cat1.colors.push("green");
console.log(cat1.colors); // ['red', 'blue', 'green']
console.log(cat2.colors); // ['red', 'blue'] - 互不影响

支持向父类传递参数

const cat = new Cat("Garfield", 5);
cat.sayName(); // "My name is Garfield"

方法复用

console.log(cat1.sayName === cat2.sayName); // true (共享原型方法)

正确的继承关系检查

console.log(cat1 instanceof Cat); // true
console.log(cat1 instanceof Animal); // true
console.log(cat1.constructor === Cat); // true

组合继承的缺点

父类构造函数被调用两次

function Animal(name) {
  console.log("Animal constructor called");
  // ...
}

function Cat(name) {
  Animal.call(this, name); // 第一次调用
}

Cat.prototype = new Animal(); // 第二次调用

原型对象上存在冗余属性

const cat = new Cat("Tom");
console.log(cat); // 实例自身有name和colors
console.log(Object.getPrototypeOf(cat)); // 原型上也有name和colors

原型式继承

原型式继承（Prototypal Inheritance）是一种不涉及构造函数的继承方式，它直接基于现有对象创建新对象，是 JavaScript 中最纯粹的面向对象继承方式。

原型式继承不关注构造函数，而是关注对象之间的关系。它的核心是：创建一个新对象，并将一个已有的对象作为这个新对象的原型。

示例

const animalPrototype = {
  isAlive: true,
  colors: ["black", "white"],
  sayHello: function () {
    console.log(`Hello, I have ${this.colors.join(" and ")} fur.`);
  },
};

const cat1 = Object.create(animalPrototype);

cat1.name = "Tom";
cat1.age = 2;

cat1.sayHello();

console.log(cat1.isAlive);

console.log(cat1.name);

原型式继承的特点

优点

更符合原型本质：它完美地体现了 JavaScript 的原型思想——任何对象都可以是另一个对象的原型，而无需“类”作为中介。
语法简单直接：一行 Object.create() 即可建立继承关系，非常清晰。
可以继承普通对象：继承的来源可以是一个简单的字面量对象，而不仅限于构造函数的实例。

缺点

引用类型属性共享问题：这是它与“原型链继承”共有的致命弱点。所有继承自同一个原型的实例，都会共享原型上的引用类型属性。如果一个实例修改了该属性，会影响到所有其他实例。
```
const cat2 = Object.create(animalPrototype);

cat1.colors.push("yellow");

// cat2 的 colors 属性也受到了影响
console.log(cat2.colors); // 输出: ['black', 'white', 'yellow']
```
属性初始化复杂：由于没有构造函数来统一处理初始化，每创建一个新对象后，都需要手动为其添加新的实例属性（如 cat1.name = 'Tom'），如果属性多，会比较繁琐。

寄生式继承

寄生式继承（Parasitic Inheritance）是 JavaScript 中一种特殊的继承模式，它基于原型式继承，通过”寄生”的方式增强对象的功能。

核心概念

寄生式继承的核心思想是：

基于现有对象创建新对象（使用原型式继承）
增强新对象的功能（添加新属性和方法）
返回增强后的对象

基本实现

function createEnhancedObject(original) {
  const clone = Object.create(original);
  clone.sayHello = function () {
    console.log("Hello, I am " + this.name);
  };

  return clone;
}
// 使用示例
const person = {
  name: "John",
  age: 30,
};

const enhancedPerson = createEnhancedObject(person);
enhancedPerson.sayHello();
console.log(enhancedPerson.age);

寄生式继承的优缺点

优点

简单灵活：不需要定义构造函数
功能增强：可以自由添加新功能
对象定制：每个对象可以有独特的增强
兼容性好：适用于各种 JavaScript 环境缺点
方法无法复用

const obj1 = createEnhancedObject({});
const obj2 = createEnhancedObject({});
console.log(obj1.sayHello === obj2.sayHello); // false

引用类型共享问题

const original = { list: [1] };
const obj1 = createEnhancedObject(original);
obj1.list.push(2);
const obj2 = createEnhancedObject(original);
console.log(obj2.list); // [1, 2]

无法使用 instanceof 检查类型

console.log(enhancedPerson instanceof Object); // true
// 但无法检查是否是特定"类型"

寄生组合式继承

寄生组合式继承（Parasitic Combination Inheritance）是 JavaScript 中最完善的继承模式，它结合了构造函数继承和原型链继承的优点，同时完美规避了它们的缺点。

核心概念

寄生组合式继承的核心思想是：

使用构造函数继承来继承父类的实例属性
使用寄生式继承来继承父类的原型方法
避免调用父类构造函数两次（解决组合继承的主要缺点）

示例

function Animal(name) {
  this.name = name || "Animal";
  this.colors = ["red", "blue"];
}

Animal.prototype.sayName = function () {
  console.log("My name is " + this.name);
};

function Cat(name, age) {
  Animal.call(this, name);

  this.age = age || 1;
  this.type = "cat";
}

Cat.prototype = new Animal();
Cat.prototype.constructor = Cat;

Cat.prototype.meow = function () {
  console.log("Meow! I am " + this.age + " years old.");
};

寄生组合式继承的优势

解决引用类型共享问题

const cat1 = new Cat("Tom", 2);
const cat2 = new Cat("Jerry", 1);

cat1.colors.push("green");
console.log(cat1.colors); // ['red', 'blue', 'green']
console.log(cat2.colors); // ['red', 'blue'] - 互不影响

支持向父类传递参数

const cat = new Cat("Garfield", 5);
cat.sayName(); // "My name is Garfield"

方法复用

console.log(cat1.sayName === cat2.sayName); // true (共享原型方法)

正确的继承关系检查

console.log(cat1 instanceof Cat); // true
console.log(cat1 instanceof Animal); // true
console.log(cat1.constructor === Cat); // true

寄生组合式继承的缺点

父类构造函数被调用两次

function Animal(name) {
  console.log("Animal constructor called");
  // ...
}

function Cat(name) {
  Animal.call(this, name); // 第一次调用
}

Cat.prototype = new Animal(); // 第二次调用

原型对象上存在冗余属性

const cat = new Cat("Tom");
console.log(cat); // 实例自身有name和colors
console.log(Object.getPrototypeOf(cat)); // 原型上也有name和colors

Class 继承

class 语法是 JavaScript 现有原型继承模型的“语法糖”（Syntactic Sugar）。它并没有引入新的继承机制，而是提供了一套更清晰、更简洁的语法来操作原型和构造函数。 ES6 Class 继承的核心思想是：使用 extends 关键字来实现类之间的继承关系。它极大地简化了继承的写法，并解决了传统原型链继承的一些痛点。

示例

class Animal {
  constructor(name) {
    this.name = name || "Animal";
    this.colors = ["red", "blue"];
  }
  sayName() {
    console.log("My name is " + this.name);
  }
}
class Cat extends Animal {
  constructor(name, type) {
    super(name);
    this.type = type || "cat";
  }
  meow() {
    console.log("Meow!");
  }
}
const cat1 = new Cat("Tom", "橘猫");
cat1.sayName();
cat1.meow();
console.log(cat1.name);
console.log(cat1.type);

Class 继承的特点

优点

语法清晰，符合直觉：class 和 extends 的写法让代码更易于阅读和理解，对有其他面向对象语言（如 Java、C++、Python）背景的开发者非常友好。
解决了原型链继承的核心痛点：
- 完美解决引用属性共享问题：父类的实例属性（如 this.colors）是在子类 constructor 中通过 super() 调用时才创建的，每个子类实例都有自己的一份，互不影响。
```
const cat1 = new Cat("Tom");
const cat2 = new Cat("Jerry");

cat1.colors.push("green");

console.log(cat1.colors); // ['red', 'blue', 'green']
console.log(cat2.colors); // ['red', 'blue'] - 未受影响！
```
内置 super 关键字：super 提供了简洁的方式来调用父类的构造函数和方法，代码更健壮。
类内部默认使用严格模式：class 和模块的内部，默认就是严格模式 ('use strict')，所以不需要再显式声明，有助于编写更规范、更安全的代码。

缺点

并非新的继承机制：它本质上还是原型继承，对于不了解原型机制的开发者来说，可能会对一些底层行为感到困惑。它是一个强大的“语法糖”，但不是一个全新的模型。
兼容性问题：class 语法是 ES6 (2015 年) 的标准，在一些非常老旧的浏览器（如 IE11）上不支持。但在现代前端开发中，通常会使用 Babel 等工具将其转换为 ES5 兼容的代码，所以这已经不是一个主要障碍。

JavaScript 字符串详解

Wed, 05 Nov 2025 10:44:20 GMT

创建字符串

1.使用字面量(推荐)：这是最常用、最直接的方式。你可以用单引号 (')、双引号 (") 或反引号 (`) 把文本包起来

let singleQuote = "单引号";
let doubleQuote = "双引号";
let templateLiteral = `反引号`;

2.使用String 构造函数（不推荐） 这种方式会创建一个字符串对象 (Object)，而不是一个基本类型的值，可能会在比较时产生意想不到的结果。

let strObject = new String("这是一个字符串对象");
console.log(typeof strObject); // "object"
let strLiteral = "这是一个字符串字面量";
console.log(typeof strLiteral); // "string"

字符串的不可变性

一旦一个字符串被创建，它的内容就永远无法被改变。

let greeting = "Hello";
greeting = greeting + ", World!"; // 拼接
console.log(greeting); // "Hello, World!"

表面上看，greeting 变量的值被改变了。但实际上，内存中发生的事情是：greeting + ", World!" 创建了一个全新的字符串 "Hello, World!"。然后 greeting 变量的“指针”从旧的 "Hello" 指向了这个新的字符串。

字符串的属性和方法

charAt(index)

功能：返回字符串中指定索引位置的单个字符。
参数：index (必需): 一个整数，表示你想要获取的字符的索引 (从 0 开始)。
返回值：一个只包含单个字符的新字符串。如果 index 超出范围，返回一个空字符串 ""。
无法正确处理超出基本多文种平面 (BMP) 的 Unicode 字符,因为 JavaScript 内部使用 UTF-16 编码来表示字符串,在需要处理可能包含 emoji 或其他特殊字符的字符串时，应避免使用 charAt()。推荐使用 ES6 提供的展开运算符 (…)、Array.from() 或 for…of 循环，它们能够正确识别并处理完整的 Unicode 字符。

let str = "JavaScript";
// 获取第一个字符
console.log(str.charAt(0)); // "J"
// 获取第五个字符
console.log(str.charAt(4)); // "S"
// 如今更常用方括号 str[0] 的写法，但它在索引越界时返回 undefined。
let emojiStr = "Hello";

// 这个字符串的 length 并不是 6，而是 7 因为 "" 这个 emoji 占了两个码元
console.log(emojiStr.length); // 7

slice(startIndex, endIndex)

功能：提取字符串的一个片段，并以新字符串的形式返回它，原始字符串不会被修改。
参数： startIndex (必需): 开始提取的索引。如果为负数，则从字符串尾部开始计算。endIndex (可选): 结束提取的索引 (该索引处的字符不被包含)。如果省略，则提取到字符串末尾。如果为负数，也从尾部计算。
返回值：包含提取部分的新字符串。
开始索引 startIndex 大于或等于结束索引 endIndex，slice() 方法将始终返回一个空字符串 ""。它不会像 substring() 那样自动交换参数。如果传递给 slice() 的参数不是数字，JavaScript 会尝试将它们隐式转换为数字。

let text = "The quick brown fox";
// 提取 "quick"
console.log(text.slice(4, 9)); // "quick"
// 从索引 10 到末尾
console.log(text.slice(10)); // "brown fox"
// 提取最后 3 个字符
console.log(text.slice(-3)); // "fox"

let data = "0123456789";
// null 被转换为 0, true 被转换为 1
console.log(data.slice(2, 1)); // ""空的
console.log(data.slice(null, true)); // "0" (相当于 slice(0, 1))

substring(startIndex, endIndex)

功能：与 slice() 类似，提取字符串的片段并返回。
参数：startIndex (必需): 开始提取的索引。endIndex (可选): 结束提取的索引 (不包含)。
返回值：包含提取部分的新字符串。
如果传递给的参数不是数字，JavaScript 会尝试将它们隐式转换为数字。
与 slice() 的核心区别：

不支持负数索引：任何负数参数都会被视为 0。
参数位置可互换：如果 startIndex 大于 endIndex，方法会自动交换这两个参数。

let str = "Mozilla";
console.log(str.substring(1, 4)); // "ozi"
// 自动交换参数 4 和 1
console.log(str.substring(4, 1)); // "ozi"
// 负数被视为 0
console.log(str.substring(-2, 4)); // "Mozi" (相当于 substring(0, 4))

includes(searchValue, position)

功能：判断一个字符串是否包含另一个指定的子字符串。
参数: searchValue (必需): 要查找的子字符串。
position (可选): 开始搜索的索引位置，默认为 0, 如果 position 是负数或 NaN，也会被当作 0。
返回值： true (如果找到) 或 false (如果未找到)。
includes() 方法的搜索是严格区分大小写的。如果要进行不区分大小写的搜索，需要先将原字符串和搜索字符串转换为相同的大小写（通常是全小写或全大写），如果是搜索空字符串 ("")返回 true，还可以处理 Unicode 字符。

let sentence = "Hello, welcome to the universe.";
console.log(sentence.includes("welcome")); // true
console.log(sentence.includes("world")); // false
// 从索引 8 开始搜索 "welcome"
console.log(sentence.includes("welcome", 8)); // true

indexOf(searchValue, fromIndex)

功能：查找指定子字符串首次出现的索引。
参数：searchValue (必需): 要查找的子字符串。
fromIndex (可选): 开始搜索的起始索引，默认为 0，fromIndex 是负数，会被当作 0，如果fromIndex 大于或等于字符串的长度，搜索将不会进行（除非搜索值是空字符串），并直接返回 -1。
返回值：第一个匹配项的索引。如果未找到，则返回 -1。
indexOf() 的搜索是严格区分大小写的。

let paragraph =
  "The quick brown fox jumps over the lazy dog. If the dog barked, was it a quick dog?";
// 查找第一个 "dog"
console.log(paragraph.indexOf("dog")); // 40
// 从索引 41 之后开始查找 "dog"
console.log(paragraph.indexOf("dog", 41)); // 72
// 查找一个不存在的词
console.log(paragraph.indexOf("cat")); // -1

lastIndexOf(searchValue, fromIndex)

功能：与 indexOf() 类似，但它是从字符串的末尾向前搜索，返回最后一次出现的索引。
参数：searchValue (必需): 要查找的子字符串。fromIndex (可选): 从该索引处开始向前搜索。默认为字符串的长度。
返回值：最后一个匹配项的索引，未找到则返回 -1
与 indexOf() 一样，lastIndexOf() 的搜索也是严格区分大小写的。

let paragraph =
  "The quick brown fox jumps over the lazy dog. If the dog barked, was it a quick dog?";
console.log(paragraph.lastIndexOf("dog")); // 72

startsWith(searchString, position)

功能：判断当前字符串是否以另一个给定的子字符串开头。
参数：searchString (必需): 要搜索的子字符串。
position (可选): 开始搜索的索引位置，默认为 0，如果 position 是负数，它会被当作 0。
返回值： true 或 false。
区分大小写，使用 startsWith("") 检查任何字符串，结果始终为 true。

let str = "To be, or not to be, that is the question.";
console.log(str.startsWith("To be")); // true
// 检查从索引 14 开始的子串是否以 "that" 开头
console.log(str.startsWith("that", 24)); // true

endsWith(searchString, length)

功能：判断当前字符串是否以另一个给定的子字符串结尾。
参数：searchString (必需): 要搜索的子字符串。
length (可选): length 参数是 endsWith() 一个非常独特的特性。它并不指定搜索字符串的长度，而是指定将原字符串的前 length 个字符视为要检查的子串。
返回值： true 或 false。
endsWith() 的搜索是严格区分大小写的，使用 endsWith("") 检查任何字符串，结果始终为 true，这包括指定了 length 参数的情况。

let str = "Cats are the best!";
console.log(str.endsWith("best!")); // true
// 检查前 8 个字符 "Cats are" 是否以 "are" 结尾
console.log(str.endsWith("are", 8)); // true

replace(searchValue, newValue)

功能：用某些字符替换另一些字符，或替换一个与正则表达式匹配的子串。
参数： searchValue (必需): 要被替换的字符串或正则表达式 (RegExp), 当 searchValue 是一个正则表达式时，你可以在 newValue 这个字符串中使用一些特殊字符 $ 来引用匹配到的内容 1.$&: 插入匹配到的完整子串, 2.$: 插入匹配子串左边的所有内容。newValue` (必需): newValue 不仅可以是字符串，还可以是一个函数（回调函数），这极大地增强了替换的灵活性。
返回值：一个部分或全部匹配项被替换的新字符串。

let p =
  "The quick brown fox jumps over the lazy dog. If the dog barked, was it a quick dog?";
// 当 searchValue 是字符串时，只替换第一个匹配项
console.log(p.replace("dog", "monkey"));
// "The quick brown fox ... lazy monkey. If the dog barked..."

// 使用带 g (全局)标志的正则表达式，替换所有匹配项
console.log(p.replace(/dog/g, "cat"));
// "The quick brown fox ... lazy cat. If the cat barked..."

replaceAll(searchValue, newValue)

功能：替换所有匹配的子串。
参数： searchValue (必需): 字符串或必须带 g 标志的正则表达式。newValue (必需): 用于替换的字符串或函数。
返回值：所有匹配项被替换的新字符串。
如果它的第一个参数 searchValue 是一个正则表达式，那么这个正则表达式必须包含全局标志 g。否则，会抛出一个 TypeError。这是为了防止开发者误用，因为一个不带 g 的 replaceAll 没有任何意义。

let str = "I like cats. My favorite cats are Siamese cats.";
// 使用字符串直接替换所有 "cats"
console.log(str.replaceAll("cats", "dogs")); // "I like dogs. My favorite dogs are Siamese dogs."

toLowerCase() 和 toUpperCase()

功能：分别将字符串转换为全小写或全大写。
参数：无。
返回值：转换后的新字符串, 原始字符串保持不变。

let text = "Hello World!";
console.log(text.toLowerCase()); // "hello world!"
console.log(text.toUpperCase()); // "HELLO WORLD!"

trim(), trimStart(), trimEnd()

功能：移除字符串开头、结尾或两端的空白字符 (空格、制表符、换行符等)。
参数：无。
返回值：移除空白后的新字符串, 原始字符串保持不变。

let greeting = "   Hello there!   ";
console.log(greeting.trim()); // "Hello there!"
console.log(greeting.trimStart()); // "Hello there!   "
console.log(greeting.trimEnd()); // "   Hello there!"

split(separator, limit)

功能：使用指定的分隔符将一个字符串分割成一个字符串数组。
参数： separator (必需): 用作分割依据的字符串或正则表达式。如果为空字符串 ""，则每个字符都会被分割。 limit (可选): 一个整数，限制返回的数组中的元素个数。
返回值：一个包含分割后子串的数组。

let csv = "2025,August,17,Sunday";
let parts = csv.split(",");
console.log(parts); // ["2025", "August", "17", "Sunday"]
let word = "character";
console.log(word.split("")); // ["c", "h", "a", "r", "a", "c", "t", "e", "r"]

padStart(targetLength, padString) 和 padEnd(targetLength, padString)

功能：在当前字符串的开头 (padStart) 或结尾 (padEnd) 填充指定的字符串，直到达到目标长度。
参数：targetLength (必需): 最终生成的字符串的期望长度。
padString (可选): 用来填充的字符串，默认为空格。
返回值：填充后的新字符串。
如果目标长度 targetLength 小于或等于当前字符串的长度，这两个方法将不会进行任何填充，而是直接返回原始字符串, 需要填充的长度超过了padString 的长度，padString 将会被重复使用。如果重复后的 padString 超出了所需长度，它会被从末尾截断。

let orderId = "123";
// 通常用于补全编号，如在开头补 0
console.log(orderId.padStart(8, "0")); // "00000123"

let label = "Chapter 1";
// 在结尾补点，用于对齐
console.log(label.padEnd(20, ".")); // "Chapter 1..........."

concat(…strings)

功能：将一个或多个字符串与原字符串连接合并。
参数 ...strings (必需): 一个或多个要连接的字符串。
返回值：连接后的新字符串。

let str1 = "Hello";
let str2 = "World";
console.log(str1.concat(" ", str2, "!")); // "Hello World!"
// 注意：在现代 JS 中，加号 `+` 或模板字符串 `` `${}` `` 是更常用和更高效的拼接方式。
// let result = str1 + ' ' + str2 + '!';
// let result = `${str1} ${str2}!`;

repeat(count)

功能：将字符串重复指定的次数。
参数： count (必需): 一个整数，表示重复的次数。
返回值：包含重复内容的新字符串。

repeat() 对 count 参数有严格的要求：

count 为 0: 返回一个空字符串 ""。
count 为负数: 抛出一个 RangeError 错误。
count 为无穷大 (Infinity): 抛出一个 RangeError 错误。
count 为小数: 会被向下取整。

let cheer = "Go! ";
console.log(cheer.repeat(3)); // "Go! Go! Go! "

let separatorLine = "=".repeat(20);
console.log(separatorLine); // "===================="

从输入 URL 到页面展示的完整过程

Wed, 05 Nov 2025 10:44:20 GMT

在现代 Web 开发中，理解浏览器如何处理一个 URL 是掌握性能优化、网络安全及前端架构的基石。这一过程跨越了操作系统的网络栈、复杂的分布式网络设施以及高度优化的浏览器渲染引擎。以下是该过程的详尽拆解。

一、进程协作与 URL 解析

1. 浏览器多进程架构背景

现代浏览器（如 Chrome）采用多进程架构以确保稳定性和安全性。核心进程包括：

浏览器进程 (Browser Process)：负责地址栏、书签、前进后退按钮及网络请求的调度。
网络进程 (Network Process)：专门处理底层网络协议、缓存管理及 DNS 查询。
渲染进程 (Renderer Process)：将 HTML/CSS/JS 转化为用户可交互的界面，每个标签页通常运行在独立的沙箱进程中。
GPU 进程：处理跨进程的图形绘制指令，实现硬件加速。

2. 地址栏输入判定

当地址栏接收到字符输入时，浏览器进程的 UI 线程首先启动。它会解析输入内容以区分其属性：如果是符合格式的 URL，则直接进入导航流程；如果是搜索词，则将其与预设的搜索引擎组合成搜索 URL。

3. URL 标准化与预处理

识别为 URL 后，浏览器会对字符串进行标准化。这包括自动补全协议（如 https://）、处理非 ASCII 字符的转义编码、解析主机名（Host）、端口号（Port）及路径（Path）。此时，浏览器还会检查该域名是否在 HSTS（HTTP 严格传输安全）预加载列表中，若是，则强制将所有 http:// 请求升级为 https://。

二、拦截层与多级缓存机制

在请求正式发出之前，浏览器会经历多个内部拦截检查，以减少不必要的网络往返。

1. 导航类型与 BFCache

如果是通过“前进”或“后退”按钮触发的导航，浏览器会优先检查 往返缓存（Back-Forward Cache）。若命中，浏览器将直接恢复页面的完整快照（包括 DOM、JS 状态和滚动位置），此时不会触发完整的网络请求或解析流程。

2. Service Worker 劫持

如果目标站点注册了 Service Worker，请求会被其 fetch 事件拦截。Service Worker 运行在独立线程中，可以根据自定义策略直接从 Cache Storage 返回响应，实现离线访问或极速加载。

3. HTTP 缓存策略

网络进程会检索磁盘（Disk Cache）和内存（Memory Cache）中的缓存副本：

强缓存：检查 Cache-Control（如 max-age）或 Expires。若资源未过期，直接使用本地副本，状态码显示为 200 (from cache)。
协商缓存：若强缓存失效，请求会携带 If-None-Match (ETag) 或 If-Modified-Since (Last-Modified)。服务器若确认资源未变，返回 304 Not Modified，浏览器继续使用本地旧资源。

三、网络连接建立：DNS、TCP 与 TLS

1. DNS 域名解析

若缓存未命中，浏览器需要通过 DNS 协议将域名转换为 IP 地址。解析过程具有层级性：从浏览器缓存、操作系统缓存、Hosts 文件，到递归 DNS 服务器，最后到权威 DNS 服务器。现代浏览器支持 DoH (DNS over HTTPS)，通过加密通道获取解析结果，防止域名劫持。

2. 传输层连接（TCP/QUIC）

TCP 连接：对于 HTTP/1.1 和 HTTP/2，浏览器与服务器进行“三次握手”建立可靠连接（SYN -> SYN-ACK -> ACK）。
QUIC 连接：对于 HTTP/3，基于 UDP 的 QUIC 协议将连接建立与加密握手合并，显著减少了往返时延（RTT）。

3. TLS 安全握手

在 HTTPS 场景下，TCP 建立后需进行 TLS 握手（目前主流为 TLS 1.2 或 1.3）。客户端与服务端协商加密套件、交换随机数、验证服务器数字证书的合法性，并最终生成对称加密的“会话密钥”，确保后续数据传输的私密性与完整性。

四、 HTTP 请求发送与服务端响应

1. 请求构造与优先级

连接就绪后，浏览器构造 HTTP 请求报文。报文包含请求行、Header（如 User-Agent, Cookie, Accept）及 Body。浏览器会根据资源类型（主文档、CSS、图片等）分配不同的优先级，高优先级资源会获得更多的连接资源。

2. 服务端处理链路

请求到达服务器后，通常经过负载均衡器（如 Nginx）转发至应用服务器。服务器根据请求路径执行业务逻辑、查询数据库，并生成响应报文。

3. 响应接收与 MIME 检查

浏览器接收响应头后，首先检查 Content-Type。如果是 text/html，则准备渲染；如果是 application/octet-stream，则启动下载流程。若响应头包含重定向状态码（如 301/302），则根据 Location 字段重新发起导航。

五、渲染流水线：从 HTML 到位图

一旦渲染进程接收到 HTML 字节流，复杂的渲染流水线（Rendering Pipeline）便开始运转。

1. 解析 HTML 构建 DOM 树

解析器将 HTML 字符转换为 Token，并根据嵌套关系构建 DOM 树。解析过程中，预加载扫描器 (Preload Scanner) 会提前识别并下载后续需要的 CSS 和 JS 资源，而不会等待 DOM 构建完成。

2. 解析 CSS 构建 CSSOM 树

浏览器并行下载并解析 CSS 文件，生成 CSSOM 树。CSSOM 描述了如何将样式应用于 DOM 节点。注意：CSS 的解析会阻塞 JS 的执行，因为脚本可能需要查询准确的计算样式。

3. JS 下载与执行：V8 引擎

JS 默认是阻塞解析的。当解析器遇到 <script>（无 defer/async）时，必须停止 HTML 解析，待 JS 下载并执行完毕后方可继续。V8 引擎通过词法分析、语法分析生成 AST（抽象语法树），随后通过解释器生成字节码，并利用即时编译器（JIT）将热点代码转化为机器码执行。

4. 生成渲染树 (Render Tree)

浏览器合并 DOM 和 CSSOM，生成渲染树。渲染树只包含可见节点（排除 display: none 及其子节点）。

5. 布局 (Layout)

布局阶段计算渲染树中每个节点在屏幕上的几何信息（位置、大小）。这是通过盒模型算法实现的，涉及父子元素间的空间分配及文本换行计算。

6. 分层与绘制 (Layer & Paint)

为了处理复杂的重叠关系（如 z-index、position: fixed），渲染进程会生成不同的 合成层 (Layers)。随后，浏览器为每个层生成绘制指令（Paint Records），记录如何画出背景、边框、文字等。

7. 合成与显示 (Compositing)

合成线程接收各图层的绘制指令，将图层切分为瓦片（Tiles），并调用 GPU 进程进行光栅化（将指令转为位图）。最后，GPU 将各层合并并输出到屏幕缓冲区，用户正式看到页面。

六、页面交互与事件循环

页面显示后，渲染进程并未停止。它进入了持续的事件循环 (Event Loop) 阶段：

宏任务与微任务：JS 执行栈清空后，优先处理微任务队列（如 Promise 回调），然后从宏任务队列（如定时器、IO 回调）取出一个执行。
交互响应：用户的点击、滚动事件由浏览器进程捕获后分发至渲染进程，通过事件监听器触发 JS 代码。
持续渲染：任何 DOM 或样式的修改都可能触发重新布局（Reflow）或重绘（Repaint），渲染流水线会循环执行以保持界面更新。

总结：深度思考

导航与渲染并非线性过程，而是高度并发且相互依赖的。性能优化的核心往往在于：

减少网络往返（利用 HSTS、HTTP/3、CDN）。
优化关键渲染路径（减少阻塞 CSS、合理使用 defer/async）。
减轻主线程负担（利用合成层、避免强制同步布局、使用 Web Workers）。

掌握这一全流程，便能从底层逻辑上理解 Web 应用的运行本质。

HTTP入门

Sun, 12 Oct 2025 18:55:38 GMT

HTTP 协议的核心哲学

无状态：一种被误解的”缺陷”

很多人对 HTTP 的无状态性嗤之以鼻，认为这是协议的重大缺陷。但这恰恰是 HTTP 能够支撑整个互联网的关键设计。

无状态不是缺陷，而是一种深思熟虑的架构选择。

HTTP的无状态性让服务端水平扩展变得异常简单。每个请求携带完整上下文，任何服务器实例都能独立处理。这就像优秀的函数式编程思想 - 纯函数不依赖外部状态，易于测试和并行化。

# `有状态`的设计问题
用户 -> 服务器A: 登录成功
用户 -> 服务器B: 请求数据 (B不知道用户已登录)
服务器B -> 用户: 请先登录

# `无状态`的优雅
用户 -> 任意服务器: 请求 + Token
任意服务器 -> 用户: 响应数据

文本协议的智慧

用户报告上传文件时偶尔失败的抓包：

POST /upload HTTP/1.1
Host: api.example.com
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Length: 1024000
------WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="file"; filename="document.pdf"
Content-Type: application/pdf

[二进制数据]
------WebKitFormBoundary7MA4YWxkTrZu0gW--

边界字符串的错误立即显而易见。如果是二进制协议，可能需要专业的解析工具才能发现问题。

文本协议牺牲了少量性能，但获得了无与伦比的调试便利性。这是一个典型的性能与可维护性的权衡。

分层架构的思想

HTTP 延续了 TCP/IP 的分层哲学，每一层都有明确的职责。这种分层不是随意的技术划分，而是对复杂性的优雅管理。HTTP 站在 TCP 的肩膀上，专注于应用层语义，让专业的层做专业的事。

深入 CORS：同源策略

为什么需要同源策略？

同源策略是 Web 安全的基石，它源于一个深刻的洞察：浏览器中的代码运行在用户环境中，而不是开发者环境中。

设想没有同源策略的世界：

恶意网站可以读取你的银行余额
攻击者可以以你的名义发送邮件
任何网站都能访问你的内部系统

CORS 不是限制，而是一种保护机制。

CORS 预检请求

CORS的预检请求设计的智慧：

# 简单请求 - 直接发送
GET /api/data HTTP/1.1
Origin: https://example.com

# 复杂请求 - 先预检
OPTIONS /api/data HTTP/1.1
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type, X-Custom-Header

# 服务器响应
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: PUT
Access-Control-Allow-Headers: Content-Type, X-Custom-Header

预检请求体现了一种”先询问，后行动”的安全哲学，它避免了对服务器的意外修改，特别是对于可能有副作用的请求。

CORS 与 CSRF

在理解了CORS后，重新审视了CSRF（跨站请求伪造）防护。这两个概念经常让开发者混淆，但它们解决的是不同层面的安全问题。

# CORS解决的问题：是否允许跨域读取响应
浏览器 -> A站点: 从B站点获取数据
B站点 -> 浏览器: 这里是你请求的数据
浏览器 -> A站点: 根据CORS配置决定是否提供数据

# CSRF解决的问题：是否执行跨域状态改变操作
用户 -> 银行站点: 登录
攻击者站点 -> 用户浏览器: 发送转账请求到银行
用户浏览器 -> 银行站点: 携带用户凭证的转账请求
银行站点: 根据CSRF Token验证请求的合法性

CORS控制的是信息的读取权限，CSRF防止的是未授权的状态改变，这两种机制相互补充，共同构建了 Web 应用的安全防线。

HTTP 性能优化

连接复用

HTTP/1.0 时代，每个资源都需要新建一个 TCP 连接。这种设计在网页简单时是合理的，但随着网页复杂度增加，性能问题凸显。

连接复用的核心思想是”连接即资源”，应该被珍惜和重用。

# HTTP/1.0 - 每个请求新建连接
域名解析 -> TCP连接 -> HTTP请求 -> HTTP响应 -> TCP断开
域名解析 -> TCP连接 -> HTTP请求 -> HTTP响应 -> TCP断开
域名解析 -> TCP连接 -> HTTP请求 -> HTTP响应 -> TCP断开

# HTTP/1.1 Keep-Alive - 连接复用
域名解析 -> TCP连接 -> HTTP请求 -> HTTP响应
                    -> HTTP请求 -> HTTP响应
                    -> HTTP请求 -> HTTP响应 -> TCP断开

这种优化看似简单，但背后体现了对资源利用效率的深刻思考。任何优化都是权衡，没有银弹。

缓存策略

HTTP缓存可能是 Web 性能优化中最被低估的特性。深入理解 ETag、Last-Modified、Cache-Control 的交互机制，让你更懂HTTP缓存策略。

# 强缓存 - 客户端直接复用，不发送请求
Cache-Control: max-age=3600
Expires: Wed, 21 Oct 2025 07:28:00 GMT

# 协商缓存 - 客户端发送验证请求
If-Modified-Since: Wed, 21 Oct 2025 07:00:00 GMT
If-None-Match: "5d8c72a5edda3"

# 服务器响应
HTTP/1.1 304 Not Modified
# 或
HTTP/1.1 200 OK
ETag: "5d8c72a5edda3"
Last-Modified: Wed, 21 Oct 2025 07:28:00 GMT

缓存策略的本质是”空间换时间”的经典算法思想在网络协议中的应用。

压缩算法

Gzip 压缩是另一个 HTTP 特性。让我们感受一下压缩前后的数据对比：

# 原始响应
Content-Type: application/json
Content-Length: 10240
{"users":[{"id":1,"name":"Alice","email":"alice@example.com"},...]}

# 压缩后响应
Content-Type: application/json
Content-Encoding: gzip
Content-Length: 1240
[二进制压缩数据]

约 90%的压缩率！ 但是它需要 CPU 资源，会增加服务器响应延迟。这是 HTTP 设计的另一个哲学：协议应该提供机制，而不是策略。

HTTP/2 和 HTTP/3

HTTP/2 的多路复用

HTTP/1.1 的管道化（Pipelining）尝试解决并行请求问题，但因为队头阻塞（Head-of-line Blocking）而失败。HTTP/2 的多路复用用全新的思路解决了这个问题：

# HTTP/1.1 - 队头阻塞问题
请求1 -> 响应1 (慢)
请求2 -> 等待响应1完成
请求3 -> 等待响应2完成

# HTTP/2 - 真正的多路复用
流1: 请求1 -> 响应1片段
流2: 请求2 -> 响应2片段
流3: 请求3 -> 响应3片段
流1: 响应1片段
流2: 响应2片段

多路复用的思想突破在于：把请求-响应对抽象为独立的”流”，在单一连接上交错传输。

HTTP/3 的 QUIC

深入研究 QUIC 协议：

# TCP的队头阻塞问题
TCP数据包1 -> 丢失
TCP数据包2 -> 必须等待数据包1重传
TCP数据包3 -> 必须等待数据包1重传
应用层: 全部阻塞

# QUIC的流级隔离
QUIC流1数据包 -> 丢失，只影响流1
QUIC流2数据包 -> 正常传输，不受影响
QUIC流3数据包 -> 正常传输，不受影响
应用层: 流2和流3正常进行

QUIC 的核心思想是：在 UDP 之上重新实现 TCP 的可靠传输特性，但解决 TCP 的固有问题。

QUIC 的 0-RTT 连接建立：

# TCP+TLS 1.3 - 至少2-RTT
客户端 -> 服务器: TCP SYN
服务器 -> 客户端: TCP SYN+ACK
客户端 -> 服务器: TCP ACK + TLS ClientHello
服务器 -> 客户端: TLS ServerHello + 数据

# QUIC - 0-RTT恢复连接
客户端 -> 服务器: 初始包 + 请求数据
服务器 -> 客户端: 响应数据

这种优化背后的思想是：利用之前连接的”记忆”跳过不必要的握手步骤。

协议演进的统一思想

回顾 HTTP 的演进历程：

HTTP/1.0 到 HTTP/1.1：连接的复用和优化
HTTP/1.1 到 HTTP/2：应用层并行的突破
HTTP/2 到 HTTP/3：传输层问题的根本解决

每一代协议的优化都针对上一代的核心痛点，但保持了应用层语义的兼容性。

HTTP 协议的永恒思想

分层与抽象

HTTP 协议的设计体现了计算机科学中的一个核心思想：通过分层抽象管理复杂性。

应用层: HTTP语义 - URL、方法、状态码、头部
传输层: TCP/QUIC - 可靠传输、流量控制、拥塞避免
网络层: IP - 路由、寻址、分片
链路层: Ethernet/WiFi - 帧传输、错误检测
物理层: 电缆/光纤 - 比特传输

每一层都有明确的职责和边界，上层不需要了解下层的实现细节。

机制与策略分离

HTTP协议很少规定具体的使用策略，而是提供灵活的机制让应用层决定。

缓存：HTTP 定义了缓存机制，但具体缓存策略由应用决定
压缩：HTTP 支持多种压缩算法，选择合适的算法是应用的责任
认证：HTTP 提供认证框架，具体认证方式可以自定义
安全：HTTP 可以升级到 HTTPS，但是否升级由应用决定

这种分离让 HTTP 协议既强大又灵活，能够适应各种应用场景。

向后兼容

HTTP 协议的一个重要特点是极强的向后兼容性。HTTP/2 和 HTTP/3 都能在必要时优雅降级到 HTTP/1.1，这保证了互联网的稳定发展。

HTTP/2服务器 -> 客户端: 我能支持HTTP/2
HTTP/2客户端 -> 服务器: 好的，我们用HTTP/2

HTTP/2服务器 -> 老旧客户端: 我能支持HTTP/2
老旧客户端 -> 服务器: 我不懂HTTP/2，用HTTP/1.1吧
服务器 -> 老旧客户端: HTTP/1.1 200 OK

系统升级应该渐进式，而不是革命式。

总结

HTTP 协议的核心特性：

简单性 - 无状态设计
抽象分层 - TCP/IP 分层
向后兼容 - 协议演进
机制与策略分离 - 缓存、压缩等
安全性 - CORS、HTTPS
性能优化 - 连接复用、缓存、压缩

HTTP 不仅是一个协议，更是一种思维方式，一套解决复杂问题的哲学体系。

“完美不是指不能再增加什么，而是指不能再减少什么。” - 安托万·德·圣埃克苏佩里

TCP入门

Sun, 12 Oct 2025 18:55:38 GMT

TCP 报文协议

TCP 头部字段主要有序列号，确认号，源端口，目的端口号，标记位，头部长度，窗口大小等，其中源端口和目的端口都是 16 位，源端口是发送方使用的端口号，目的端口是接收方使用的端口号，序列号和确认号都是 32 位，序列号可以保证数据的有效性，确认号可以保证数据的可靠性，下面我们来逐个分解。

源端口：16 位字节，发送方进程。
目的端口：16 位字节，接收方进程。
序列号：32 位字节，给每一个字节都设置一个序号，接收方可以根据序号对接收到的数据进行排序。
确认号：32 位字节，告诉发送法我收到了序号 N-1 之前的所有数据，并且通知对方下次从序号 N 开始发送。
数据偏移／首部长度：4 位字（一字是 4 字节），因为 TCP 的首部长度是不固定的，用来表示真正有效的数据，相对于整个 TCP 段的起始位置偏移了多少, 有利于接收方裁剪识别。
保留：6 位字节，是协议设计者为未来预留的“空白地盘”。
校验和：16 位字节，用来检查数据在接收的时候是否损坏。
窗口：16 位字节，告诉发送法我这里还能存储多少字节的数据。
紧急指针：16 位字节，一个特殊的插队机制。
选项和填充：选项 MSS - 告诉对方，我能接收的单个数据包最大是多少，填充 SACK - 如果丢了第 5 个包，但收到了第 6、7 个，SACK 可以告诉发送方“只重传第 5 个”，不用全重传。
数据部分：应用层的数据。

TCP 建立连接

TCP 三次握手，我们来详细了解一下这个过程

初始状态双方的 TCP 都处于 close，但是服务器会监听一个端口， listen 来监听。
第一次握手，客户端会生成一个随机的序列号 x 放到 TCP 协议的序列号当中，req=x，然后会将 SYN 标志设置为 1，发送给客户端，之后服务端处于 SYN-SENT 状态。
服务器接收到了客户端发送来的数据，然后生成一个随机的序列号 y 放到 TCP 报文中，发送 SYN=1, ACK=1，req=y, ack=x+1 之后服务器也处于 SYN-SENT 状态。
客户端接收到服务端发送来的数据，客户端会回一个 ACK 确认报文，该报文的确认号就是 ack=y+1, 序列号为服务端的确认号 seq=x+1, 之后客户端处于 ESTABLISHED 状态。
服务端接收到 ACK 确认报文后，服务端也处于 ESTABLISHED 状态。

为什么是三次握手而不是二次握手？ 如果只有二次握手就会导致以下两个问题

无法确定客户端是否具备接收能力，第一次握手可以确定客户端有发送能力，第二次握手可以确定服务端具备接收和发送的能力，如果没有第三次握手就无法确定客户端是否具备接收的能力。
资源浪费，当服务端接收到客户端发来的 SYN 并且确定建立连接时，服务器就会立即为连接分配资源，如果接收到了一个过期的历史资源包，这个资源包有不需要客户端的确认，就会在服务端一直挂着，耗费内存。

TCP 断开连接

TCP 四次挥手

初始状态都是 WSTABLISHED
客户端向服务端发送 FIN 报文，客户端进入 FIN_WAIT_1 状态。
服务端接收到了客户端发来的报文，于是向服务端发送 ACK 确认报文，之后服务端进入 CLOSE_WAIT 状态。
客户端接受到服务端发送来的 ACK 报文，于是进入了 FIN_WAIT_2 状态。
服务端处理完数据之后，向客户端发送 FIN 报文，之后服务端处于 LAST_ACK 状态。
客户端接受到了服务端的 FIN 报文，向服务端回了一个 ACK 报文，然后进入 TIME_AWIT 状态。
服务端接收到 ACK 报文，进入 CLOSE 状态，断开链接。
客户端在 TIME_AWIT 状态经过 2 个 MSL 后，就进入了 CLOSE 状态，客户端的连接也断开。

为什么是四次挥手而不是三次挥手？

TCP 是全双工协议，客户端和服务端都具备发送和接收的能力，所以我们要保证双方的数据都发送处理完成，才能断开。当客户端向服务端发送了一个 FIN 报文，这个时候就表示客户端的数据已经处理好了，可以断开连接了，然后服务端接收到客户端发来的 FIN 报文，于是发了一个 ACK 确认报文，说同意断开连接，但是这个时候服务端还可能没把数据处理完，所以需要等服务端处理完成之后才可以发送 FIN 报文给客户端，所以二次挥手不可与三次挥手合并，所以需要四次挥手，如果只有三次挥手，可能会导致数据丢失。

WebSocket

Sun, 12 Oct 2025 18:55:38 GMT

作为一名前端工程师，实时通信是我们必须掌握的核心技术之一。今天，我将通过一个完整的聊天室项目，带大家深入理解 WebSocket 的工作原理，并手把手教大家如何构建一个功能完善的实时聊天应用。

一、WebSocket 协议深度解析

1.1 HTTP 协议的局限性与 WebSocket 的诞生

在深入代码之前，我们必须理解为什么需要 WebSocket。传统的 HTTP 协议基于”请求-响应”模型，这种模型存在以下关键问题：

HTTP 轮询的本质缺陷：

// 传统轮询实现
setInterval(() => {
    fetch('/api/messages')
        .then(res => res.json())
        .then(data => {
            // 即使没有新消息，也会发送请求
            // 造成大量带宽浪费和服务器压力
        })
}, 1000)  // 每秒请求一次

这种方式会产生大量无效请求，假设有 1000 个用户在线，每秒就会产生 1000 个请求，而其中可能 99%都是无效的。

长轮询的改进与不足：

// 长轮询实现
function longPolling() {
    fetch('/api/messages', {
        timeout: 30000  // 30秒超时
    }).then(res => {
        // 收到消息或超时后立即发起下一次请求
        longPolling()
    })
}

长轮询虽然减少了请求次数，但服务器需要保持大量连接，且仍然无法实现服务器主动推送。

1.2 WebSocket 握手机制详解

WebSocket 通过一次 HTTP 握手升级连接，随后建立持久的双向通道。让我们深入理解这个过程：

客户端发起握手请求：

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket                    # 请求协议升级
Connection: Upgrade                   # 连接升级
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==  # 随机生成的Base64编码密钥
Sec-WebSocket-Version: 13             # WebSocket协议版本
Origin: http://example.com            # 请求来源

关键字段解析：

Upgrade: websocket：告诉服务器客户端希望升级到 WebSocket 协议
Sec-WebSocket-Key：用于安全校验，防止恶意或无意的连接
Sec-WebSocket-Version：确保客户端和服务器使用相同的协议版本

服务器响应握手：

HTTP/1.1 101 Switching Protocols      # 101状态码表示协议切换
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=  # 基于客户端Key计算的值

1.3 WebSocket 数据帧结构

WebSocket 使用帧（Frame）来传输数据，每个帧都有特定的结构：

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-------+-+-------------+-------------------------------+
|F|R|R|R| opcode|M| Payload len |    Extended payload length    |
|I|S|S|S|  (4)  |A|     (7)     |             (16/64)           |
|N|V|V|V|       |S|             |   (if payload len==126/127)   |
| |1|2|3|       |K|             |                               |
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
|     Extended payload length continued, if payload len == 127  |
+ - - - - - - - - - - - - - - - +-------------------------------+
|                               |Masking-key, if MASK set to 1  |
+-------------------------------+-------------------------------+
| Masking-key (continued)       |          Payload Data         
+-------------------------------- - - - - - - - - - - - - - - - +
:                     Payload Data continued ...                :
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
|                     Payload Data continued ...                |
+---------------------------------------------------------------+

重要字段说明：

FIN：表示是否为消息的最后一个分片
opcode：操作码，表示帧类型（文本、二进制、关闭等）
MASK：客户端发送的数据必须掩码，服务器发送的不需要
Payload：实际传输的数据

1.4 WebSocket 心跳机制

为了保持连接活跃，WebSocket 实现了 Ping/Pong 心跳机制：

// 客户端心跳实现
let heartbeatInterval;
function startHeartbeat(socket) {
    heartbeatInterval = setInterval(() => {
        if (socket.readyState === WebSocket.OPEN) {
            socket.send(JSON.stringify({ type: 'ping' }));
        }
    }, 30000);  // 每30秒发送一次心跳
}

// 服务端响应
socket.on('message', (data) => {
    const message = JSON.parse(data);
    if (message.type === 'ping') {
        socket.send(JSON.stringify({ type: 'pong' }));
    }
});

二、Socket.IO：工程化的 WebSocket 解决方案

当我们谈论实时 Web 应用时，原生 WebSocket 是基石，但它更像是一个低级别的 API，留下了许多工程化问题需要开发者自己解决，例如连接的可靠性、浏览器兼容性以及扩展性。Socket.IO 正是为解决这些痛点而生，它不是简单地封装 WebSocket，而是提供了一套完整的、经过生产环境严苛考验的实时通信框架。

2.1 为什么选择 Socket.IO？—— 超越基础连接

选择 Socket.IO 的核心理由在于它为开发者“包办”了那些构建健壮实时应用时最棘手、最繁琐的工作。

1. 自动降级机制 (Automatic Fallback): 这是 Socket.IO 最著名的特性。它确保了您的应用能在任何网络环境下工作，即使在不支持 WebSocket 的旧版浏览器或被企业防火墙限制的网络中。

// Socket.IO 会按以下顺序智能地选择最佳传输方式
const transports = [
    'websocket',        // 首选：最高效的双向通信
    'webtransport',     // 实验性：基于 HTTP/3 的新一代传输协议
    'polling'           // 降级方案：可靠的 HTTP 长轮询
];
// Flash Socket 已被废弃，不再使用

深度思考：这个机制的价值在于可靠性。当用户的网络环境（例如公司防火墙封锁了 WebSocket 端口）阻止了 WebSocket 连接时，应用不会直接失败，而是无缝降级到 HTTP 长轮询，保证了核心功能的可用性。

2. 自动重连机制 (Automatic Reconnection): 网络是不可靠的。移动设备进出隧道、Wi-Fi 切换、短暂的网络波动都可能导致连接中断。Socket.IO 内置了一套强大的自动重连逻辑，采用了**“指数退避 (Exponential Backoff)”**策略。

// Socket.IO 默认的智能重连配置
const socket = io({
    reconnection: true,              // 启用自动重连（默认）
    reconnectionAttempts: Infinity,  // 无限次尝试
    reconnectionDelay: 1000,         // 初始延迟1秒
    reconnectionDelayMax: 5000,      // 最大延迟5秒
    randomizationFactor: 0.5         // 随机因子，避免"惊群效应"
});

“指数退避”和“随机因子”是工程化的体现。它避免了在服务器宕机恢复后，成千上万的客户端在同一时刻发起重连请求，从而压垮服务器。

3. 内置心跳机制 (Built-in Heartbeat): 原生 WebSocket 需要开发者手动实现心跳来防止连接被中间代理超时断开。Socket.IO 则内置了心跳机制，通过周期性的 ping/pong 包自动维持连接活性，并检测“僵尸连接”。

4. 房间和命名空间 (Rooms & Namespaces): 这是 Socket.IO 在服务器端扩展性的关键。

命名空间 (Namespaces)：像 API 的不同端点（/users, /orders），用于在单个连接上隔离不同的业务逻辑。
房间 (Rooms)：在命名空间内，用于向特定的客户端子集广播消息（如群聊、订阅特定频道）。

// 服务器端 (Node.js)
// 命名空间：隔离不同的功能模块
const chatNamespace = io.of('/chat');
const adminNamespace = io.of('/admin');

chatNamespace.on('connection', (socket) => {
    // 房间：实现群组功能
    socket.join('room1');
    // 向 'room1' 房间内的所有客户端（包括发送者）发送消息
    chatNamespace.to('room1').emit('message', 'A new user has joined Room1');
});

5. 消息确认 (Acknowledgements): 支持 emit 时附加回调函数，实现类似 RPC (远程过程调用) 的请求-响应模式，方便地确认消息是否被对方收到并处理。

实现效果 :

三、客户端核心实现详解（chat.js）

现在让我们深入分析客户端的核心代码实现。

3.1 连接建立与初始化

const socket = io.connect()

这行代码背后发生了什么？

1. 协议自动识别：

// Socket.IO内部实现
function connect() {
    const protocol = window.location.protocol === 'https:' ? 'wss:' : 'ws:';
    const url = `${protocol}//${window.location.host}`;
    return new WebSocket(url);
}

2. 连接状态管理：

// Socket.IO维护的连接状态
socket.on('connect', () => {
    console.log('Connected:', socket.id);  // 唯一的socket ID
});

socket.on('disconnect', (reason) => {
    console.log('Disconnected:', reason);
    // 可能的原因：'io server disconnect', 'ping timeout', 'transport close'
});

3.2 登录流程的完整实现

page.onLogin = function(username){
    console.log(username)
    socket.emit('login', username)
}

socket.on("login",(result)=>{
    if(result){
        page.intoChatRoom()
        socket.emit('users','')  // 请求用户列表
    }else{
        alert('用户名已被占用')
    }
})

登录流程时序图：

客户端                     服务器
  |                          |
  |----emit('login')-------->|
  |                          | 验证用户名
  |<---emit('login',true)----|
  |                          |
  |----emit('users')-------->|
  |                          | 发送用户列表
  |<---emit('users',[...])---|

关键设计点：

用户名验证时机： 在服务器端进行验证，确保数据一致性
异步处理： 使用事件机制处理异步响应，不阻塞 UI
状态同步： 登录成功后立即获取用户列表，保持状态一致

3.3 消息发送机制深度分析

page.onSendMsg = function(from, msg, to){
    // 输入验证层
    if(!msg || !msg.trim()) return
    // 构造消息体
    const payload = {
        from,           // 发送者
        msg,            // 消息内容
        to: to || null  // 接收者，null表示群发
    }
    // 发送消息
    socket.emit('msg', payload)
    // 乐观更新UI
    page.addMsg(from, msg, to)
    page.clearInput()
}

3.4 消息接收与去重机制

socket.on('message', (data)=>{
    const { from, msg, to } = data || {}
    // 数据验证
    if(!from || !msg) return
    // 去重处理：避免显示自己发送的消息
    if(from === page.me) return
    // 渲染消息
    page.addMsg(from, msg, to)
})

3.5 用户状态实时同步

// 监听新用户加入
socket.on('userin', (user) => {
    page.addUser(user)
})
// 监听用户离开
socket.on('userout', (user) => {
    page.removeUser(user)
})
// 获取完整用户列表
socket.on('users', (users) => {
    for (const u of users) {
        page.addUser(u)
    }
})

3.6 总代码


// 连接到服务器，需要指定完整的服务器地址
const socket = io.connect('http://localhost:3000')

//客户端发送消息给服务器
page.onLogin = function(username){
  console.log(username)
  socket.emit('login', username)
}

page.onSendMsg = function(me,msg,to){
  console.log(msg)
  socket.emit('msg', {
    to,
    content: msg
  })
  page.addMsg(me,msg,to)
}

// 客户端监听服务器消息
socket.on("login",(result)=>{
  if(result){
    page.intoChatRoom()
    socket.emit('users','')
  }else{
    alert('用户名已被占用')
  }
})

// 客户端监听服务器发送的用户列表
socket.on('users', (users) => {
  for (const u of users) {
    page.addUser(u)
  }
})

// 发送消息：由 UI 回调触发
page.onSendMsg = function(from, msg, to){
  if(!msg || !msg.trim()) return
  const payload = { from, msg, to: to || null }
  socket.emit('msg', payload)
  // 本地先渲染自己的消息
  page.addMsg(from, msg, to)
  page.clearInput()
}

// 接收消息：来自其他用户或服务端转发
socket.on('message', (data)=>{
  const { from, msg, to } = data || {}
  // 忽略自己发送且已本地渲染的消息（服务端未回发给自己则无需判断）
  if(!from || !msg) return
  if(from === page.me) return
  page.addMsg(from, msg, to)
})

socket.on('userin', (user) => {
  page.addUser(user)
})

socket.on('userout', (user) => {
  page.removeUser(user)
})

四、服务端架构详解（chatSer.js）

4.1 模块化设计与数据结构

const users = []
module.exports = function (server) {
    const io = require('socket.io')(server);
    io.on('connection', (socket) => {
        // 连接处理逻辑
    })
}

4.2 连接生命周期管理

io.on('connection', (socket) => {
    console.log('New connection:', socket.id)
    // 连接建立时的初始化
    socket.data = {
        authenticated: false,
        username: null
    }
    // 设置超时断开
    const timeout = setTimeout(() => {
        if (!socket.data.authenticated) {
            socket.disconnect()
        }
    }, 10000)  // 10秒内必须完成登录
    socket.on('disconnect', () => {
        clearTimeout(timeout)
        // 清理用户数据
        const idx = users.findIndex(u => u.socket.id === socket.id)
        if (idx !== -1) {
            const [removed] = users.splice(idx, 1)
            socket.broadcast.emit('userout', removed.username)
        }
    })
})

连接管理的最佳实践：

认证超时： 防止恶意连接占用资源
资源清理： 确保断开时释放所有资源
优雅断开： 通知其他用户状态变化

4.3 登录验证与安全性

socket.on("login", (data) => {
    // 基础验证
    if (data === '所有人' || users.filter(u => u.username === data).length > 0) {
        socket.emit("login", false)
        return
    }
    // 注册用户
    users.push({
        username: data,
        socket
    })
    socket.emit('login', true)
    socket.broadcast.emit('userin', data)
})

4.4 消息路由系统的实现

socket.on('msg',(data)=>{
    const { from, to, msg } = data || {}
    if(!from || !msg) return
    if(!to){
        // 群发消息
        socket.broadcast.emit('message', { from, msg })
        return
    }
    // 私聊消息
    const target = users.find(u => u.username === to)
    if(target){
        target.socket.emit('message', { from, msg, to })
    }
})

消息路由的核心概念：

broadcast： 向除发送者外的所有连接发送
to： 向特定房间发送
emit： 向特定 socket 发送

4.5 用户列表同步机制

socket.on('users', () => {
    const arr = users.map(u => u.username)
    socket.emit('users', arr)
})

4.6 总代码


const users = []
module.exports = function (server) {
  const io = require('socket.io')(server, {
    cors: {
      origin: "*",  // 允许所有来源，包括file://
      methods: ["GET", "POST"]
    }
  });

  io.on('connection', (socket) => {
    socket.on("login", (data) => {
      let curusername = ''
      if (data === '所有人' || users.filter(u => u.username === data).length > 0) {
        socket.emit("login", false)
      }
      else {
        users.push({
          username: data,
          socket
        })
        curusername = data
        socket.emit('login', true)
        //新用户进入
        socket.broadcast.emit('userin', data)
      }
    })
    // 用户
    socket.on('users', () => {
      const arr = users.map(u => u.username)
      socket.emit('users', arr)
    })

    // 消息路由
    socket.on('msg',(data)=>{
      const { from, to, msg } = data || {}
      if(!from || !msg) return
      if(!to){
        socket.broadcast.emit('message', { from, msg })
        return
      }
      const target = users.find(u => u.username === to)
      if(target){
        target.socket.emit('message', { from, msg, to })
      }
    })

    socket.on('disconnect', () => {
      const idx = users.findIndex(u => u.socket.id === socket.id)
      if (idx !== -1) {
        const [removed] = users.splice(idx, 1)
        // 通知其他客户端有人离开（如果前端监听的话）
        socket.broadcast.emit('userout', removed.username)
      }
    })
  });
}

五、UI 层架构设计（ui.js）

5.1 模块化封装模式

const page = (function () {
    // 私有变量
    const userList = $(".users");
    const chatList = $(".chat-list");
    // 私有方法
    function formatTime(timestamp) {
        const date = new Date(timestamp)
        return `${date.getHours()}:${date.getMinutes()}`
    }
    // 公开接口
    return {
        me: null,
        intoChatRoom,
        addUser,
        addMsg,
        // ...
    }
})();

IIFE 模式的优势：

避免全局污染： 所有变量都在函数作用域内
信息隐藏： 只暴露必要的接口
单例模式： 确保只有一个实例

5.2 DOM 操作优化

function addMsg(from, msg, to) {
    // 创建消息元素
    const li = $("<li>")
        .html(`<span class="user">${from}</span> <span class="gray">对</span>
    <span class="user">${to ? to : "所有人"}</span> <span class="gray">说：</span> `);
    // 防XSS：使用text()而非html()
    const msgSpan = $("<span>").text(msg);
    li.append(msgSpan).appendTo(chatList);
    // 自动滚动到底部
    chatList.scrollTop(chatList.prop("scrollHeight"), 0);
}

5.3 事件处理与用户交互

// 事件委托处理用户列表点击
userList.click((e) => {
    if (e.target.tagName === "LI") {
        $(".sendmsg .user").text(e.target.innerText);
    }
});
  
// 回车发送消息
$(".sendmsg input").keydown((e) => {
    if (e.key === "Enter") {
        page.onSendMsg &&
            page.onSendMsg(page.me, $(e.target).val(), page.getTargetUser());
    }
});

5.4 总代码

const page = (function () {
  const userList = $(".users");
  const chatList = $(".chat-list");
  function intoChatRoom() {
    $(".login").hide();
    $(".chat").show();
  }

  function addUser(userName) {
    $("<li>").text(userName).attr("user", userName).appendTo(userList);
    const number = +$(".user-list .title span").text();
    $(".user-list .title span").text(number + 1);
    addLog(`<span class="user">${userName}</span> 进入聊天室`);
    chatList.scrollTop(chatList.prop("scrollHeight"), 0);
  }

  function addLog(log) {
    $("<li>").addClass("log").html(log).appendTo(chatList);
  }

  function removeUser(userName) {
    const li = userList.find(`li[user="${userName}"`);
    if (!li.length) {
      return;
    }
    li.remove();
    const number = +$(".user-list .title span").text();
    $(".user-list .title span").text(number - 1);
    addLog(`<span class="user">${userName}</span> 退出了聊天室`);
  }

  function clearInput() {
    $(".sendmsg input").val("");
  }

  function addMsg(from, msg, to) {
    const li = $("<li>")
      .html(`<span class="user">${from}</span> <span class="gray">对</span> 
    <span class="user">${
      to ? to : "所有人"
    }</span> <span class="gray">说：</span> `);
    const msgSpan = $("<span>").text(msg);
    li.append(msgSpan).appendTo(chatList);
    chatList.scrollTop(chatList.prop("scrollHeight"), 0);
  }

  function getTargetUser() {
    const user = $(".sendmsg .user").text();
    return user === "所有人" ? null : user;
  }

  function initChatRoom() {
    userList.html(`<li class="all">所有人</li>`);
    $(".user-list .title span").text(0);
    chatList.html(`<li class="log">欢迎来到渡一聊天室</li>`);
  }

  userList.click((e) => {
    if (e.target.tagName === "LI") {
      $(".sendmsg .user").text(e.target.innerText);
    }
  });

  return {
    me: null,
    intoChatRoom,
    initChatRoom,
    addUser,
    addLog,
    removeUser,
    addMsg,
    clearInput,
    getTargetUser,
    onLogin: null,
    onSendMsg: null,
  };
})();

(function () {
  $(".login input").keydown((e) => {
    if (e.key === "Enter") {
      page.me = $(e.target).val();
      page.onLogin && page.onLogin(page.me);
    }
  });
  $(".sendmsg input").keydown((e) => {
    if (e.key === "Enter") {
      page.onSendMsg &&
        page.onSendMsg(page.me, $(e.target).val(), page.getTargetUser());
    }
  });
})();

HTML 实现

<!DOCTYPE html>
<html lang="en">

<head>
  <meta charset="UTF-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0" />
  <title>在线聊天室</title>
  <link rel="stylesheet" href="./css/global.css" />
  <link rel="stylesheet" href="./css/index.css" />
</head>

<body>
  <div class="login">
    <div class="form">
      <h1>请输入你的昵称，回车后进入聊天室</h1>
      <input type="text" placeholder="请输入你的昵称"/>
    </div>
  </div>
  <div class="chat" style="display: none;">
    <div class="user-list">
      <div class="title">在线人数：<span>0</span></div>
      <ul class="users">
        <li class="all">所有人</li>
      </ul>
    </div>

    <div class="main">
      <ul class="chat-list">
        <li class="log">欢迎来到聊天室</li>
      </ul>
      <div class="sendmsg">
        <span class="gray">对</span>
        <span class="user">所有人</span>
        <span class="gray">说：</span>
        <input type="text" />
      </div>
    </div>
  </div>
  <script src="https://cdn.bootcdn.net/ajax/libs/jquery/3.5.0/jquery.min.js"></script>
  <script src="js/ui.js"></script>
  <!-- Socket.IO客户端库 -->
  <script src="https://cdn.socket.io/4.5.4/socket.io.min.js"></script>
  <script src="./js/chat.js"></script>
</body>

</html>

计算机网络入门

Sun, 11 May 2025 21:44:20 GMT

计算机的发展史

什么是计算机

计算机俗称电脑，是一种用于高速计算的电子计算机器，可以进行数值计算，又可以进行逻辑计算，具备存储记忆的功能，是可以按照程序进行，自动，高速进行海量数据的现代化智能电子设备。

计算机的分类

编辑

超级计算机：气象预测、核能模拟、基因分析、人工智能训练等。
大型计算机：银行交易处理、政府数据中心、航空订票系统等。
服务器：为其他设备（客户端）提供网络服务（如数据存储、网站托管）。
小型机：企业资源管理（ERP）、科学计算等。
工作站：高性能个人计算机，专为专业领域设计（如图形渲染、工程设计）。
个人计算机：面向个人用户，包括台式机、笔记本电脑、平板电脑等。
嵌入式计算机：集成在设备内部，执行特定功能（如智能家电、汽车控制系统、医疗设备）。

计算机的发展历史

早期计算设备（19 世纪 - 20 世纪初）

机械计算机：“在 19 世纪，像巴贝奇的差分机这样的机械计算机，是那个时代对复杂计算需求的回应，虽然它们很笨重，但奠定了自动计算的基础。”
个人观点：机械计算机虽然受限于物理磨损和制造工艺，但其“程序控制”的思想是现代计算机的灵魂。

电子计算机的诞生（20 世纪中期）

电子管计算机（如 ENIAC）：“二战期间和战后，电子管计算机的出现，如 ENIAC，标志着计算速度的巨大飞跃，从机械时代的缓慢计算转变为电子速度。”
晶体管计算机：“晶体管的发明极大地提高了计算机的可靠性和效率，缩小了体积，为商业化铺平了道路。”

集成电路与个人计算机革命（20 世纪后期）

集成电路的发展：摩尔定律驱动了芯片性能的指数级增长。
个人计算机的兴起：Apple II 和 IBM PC 让计算力走进家庭。

互联网与现代计算（21 世纪初至今）

互联网的普及：全球化数字经济的诞生。
移动计算和人工智能：智能手机与深度学习改变了各行各业。编辑

计算机的大脑：CPU

什么是 CPU

CPU（Central Processing Unit），即中央处理器，是计算机的大脑，负责执行指令和处理数据。

指令获取与执行

工作过程：读取指令 -> 解码指令 -> 执行操作 -> 结果输出。
个人理解：CPU 的流程就像解决问题：先理解问题（解码），再思考方案（执行），最后得出答案（输出）。

主要功能单元

算术逻辑单元（ALU）：CPU 的心脏，负责所有的算术（加减乘除）和逻辑（判断）运算。
控制单元（CU）：CPU 的指挥部，协调从内存取指令、解码及控制其他部件。
寄存器：CPU 内部的高速存储单元，相当于“临时记忆”，速度远超内存。

性能指标

主频：工作频率（GHz），频率越高，单位时间执行指令越多。
核心数量：多核设计就像多条生产线，提高多任务处理能力。
缓存 (Cache)：位于 CPU 与内存之间，减少 CPU 访问慢速内存的次数。
架构和指令集：决定了 CPU 的“语言”和执行效率（如 x86, ARM）。

CPU 的分类

Intel：以稳定著称，Core（酷睿）系列面向大众，Xeon（至强）系列面向服务器。
AMD：以高性价比和多核性能著称，Ryzen（锐龙）系列深受玩家喜爱。
ARM：低功耗架构，广泛用于手机（苹果 A 系列、骁龙）和嵌入式设备。

小贴士：一般办公选 Intel，游戏/生产力追求极致可选 AMD，但这没有绝对界限，看个人需求。

选购与故障排除

指标：看主频、缓存、核数。
常见故障：

散热不良：死机、蓝屏。需清洁风扇或重涂硅脂。
超频问题：自检不通过。需恢复 BIOS 默认频率。
针脚接触不良：无法启动。检查插槽是否有异物或针脚弯曲。编辑

计算机的工作台：内存 (Memory)

内存简介与原理

内存是用于暂时存储 CPU 正在使用的数据和程序，以供快速访问。

原理：像是有许多“小抽屉”的柜子，每个抽屉有唯一编号（内存地址）。
易失性：断电后数据会消失，所以需要硬盘进行长期存储。

内存的分类

按功能：
RAM（随机存取存储器）：可读写，如 DDR4、DDR5。
ROM（只读存储器）：固件存储，通常不可随意修改。
按技术：目前主流是 DDR5，传输速率远超前代。

选购与维护

指南：关注主板兼容性（插槽类型）、容量（8G 办公，16G+ 游戏）、频率和时序（CL 值）。
故障解决：
无法开机：尝试重新插拔，用橡皮擦擦拭“金手指”。
蓝屏：使用系统自带的内存诊断工具检查。

计算机的仓库：硬盘 (Disk)

硬盘种类对比

机械硬盘 (HDD)：盘片旋转读写。容量大、便宜，适合存电影/文档。
固态硬盘 (SSD)：闪存芯片存储。速度极快（秒开机）、抗震，适合装系统和软件。

常见故障原因

系统不认硬盘：数据线松动或 BIOS 跳线设置错误。
系统无法启动：引导文件丢失（可用 PE 系统修复）。
硬盘坏道：物理坏道建议送修，逻辑坏道可用软件修复。

计算机的骨架：主板 (Motherboard)

主板的作用

主板连接并支撑所有硬件，负责数据流动的协调。

核心组件：芯片组、BIOS、CPU 插槽、内存插槽、PCIe 插槽。

选购要点

板型：ATX（大板）、Micro-ATX（中板）、Mini-ITX（小板）。
品牌：华硕（ASUS）、技嘉（Gigabyte）、微星（MSI）是御三家。
扩展性：USB 接口数量、是否自带 Wi-Fi/蓝牙。

计算机的视觉神经：显卡 (GPU)

显卡简介

显卡负责将数据转换为显示器能识别的图像信号。在现代前端开发中，GPU 也常用于网页的硬件加速渲染。

核心任务：图像生成、AI 计算、视频解码。

显卡接口演进

ISA -> 2. PCI -> 3. AGP -> 4. PCI-E (当前主流)

Vue 详细讲解

Sat, 25 Jan 2025 15:25:22 GMT

第一部分：JavaScript 基础

js 的三种书写方式：

行内：

<body>
  <button onclick="alert('行内')"></button>
</body>

内部：

<body>
  <script>
    alert("内部");
  </script>
</body>

外部：外部 js 标签中间不能书写东西

<body>
  <script src="./01.js.html"></script>
</body>

js 的输入输出：

输入语法：页面打印：document.write('页面打印')

编辑

控制台打印：console.log('控制台打印')

编辑

弹出界面：console.log('控制台打印')

编辑

输入语法：prompt('请输入信息')

编辑

注释： 单行注释：// 我是单行注释

多行注释：/* 我是多行注释 */

变量： 变量是用来储存数据的容器，简单理解就是一个盒子。

// 声明并赋值一个年龄变量
let age = 18;
// 输出
alert(age);

// 声明一个年龄变量
let age;
// 赋值
age = 18;
// 输出
alert(age);

数组：

定义数组： let arr = [1, 2, 3, 4, 5]; console.log(arr); // 输出 [1, 2, 3, 4, 5]

数组的增删改查：

增加元素：
push() 向数组的末尾添加一个或多个元素。
unshift() 向数组的开头添加一个或多个元素。
splice() 可以在任意位置插入元素。
删除元素：
pop() 从数组末尾移除并返回。
shift() 从数组开头移除并返回。
splice() 从指定位置删除元素。
修改元素： 直接通过索引修改：arr[1] = 2.5;
查询元素： indexOf(元素) 返回索引，不存在返回 -1。

数据类型：

基本数据类型（栈内存）：

number: 数值。
string: 字符串。
boolean: 布尔值（true/false）。
undefined: 未定义。
null: 空值。

引用数据类型（堆内存）：

对象 (Object): 键值对集合。
数组 (Array): 有序元素列表。
函数 (Function): 可执行的代码块。

数据转换：

隐式转换： 11 + '11' 变字符串，+'123' 变数字。
显式转换： Number()、String()、Boolean()。

运算符： 包括算数运算符（+, -, *, /, %, **）、比较运算符（==, ===, !=, !==）和逻辑运算符（&&, ||, !）。

函数： 包含函数声明、函数表达式、立即执行函数（IIFE）以及箭头函数。

对象： 创建对象可用字面量 {} 或 new Object()。支持属性的增（obj.prop = val）、删（delete obj.prop）、改、查（Object.keys/values）及 for...in 遍历。

第二部分：JavaScript 进阶 (DOM/BOM)

DOM (Document Object Model)： DOM 将文档视为树形结构。

节点类型： 元素节点、属性节点、文本节点、注释节点、文档节点。
获取节点： getElementById、getElementsByClassName、querySelector、querySelectorAll。
自定义属性： data-* 属性，通过 element.dataset 访问。

操作 Class： 使用 classList 方法：add()、remove()、toggle()、contains()。

定时器：

setTimeout / clearTimeout: 延时执行一次。
setInterval / clearInterval: 每隔一段时间执行。

事件监听：

鼠标： click, mouseenter, mouseleave (推荐，无冒泡)。
键盘： keydown, keyup。
表单： submit, input, change, focus, blur。

事件流： 经历捕获阶段、目标阶段、冒泡阶段。

阻止冒泡：e.stopPropagation()。
阻止默认行为：e.preventDefault()。

页面尺寸与位置： scroll (滚动), offset (偏移), client (视口)。编辑

日期与时间： new Date() 获取当前时间，支持获取年、月、日等。时间戳获取：Date.now() 或 +new Date()。编辑

BOM (Browser Object Model)：

location: 地址栏操作（href, reload）。
history: 历史记录（back, forward）。
localStorage: 本地存储，持久化。

第三部分：Vue2 进阶篇

组件基础： 编辑组件由 template (结构)、style (样式)、script (逻辑) 组成。

Scoped: <style scoped> 确保样式只作用于当前组件，防止污染。Vue 会通过 data-v-xxxx 属性来实现样式隔离。
Data: 在组件中 data 必须是一个函数并 return 一个对象，确保每个实例维护独立的数据拷贝。编辑

组件通信：

Props (父传子): 父组件绑定属性，子组件通过 props 接收（支持数组、对象、校验）。
$emit (子传父): 子组件通过 this.$emit('event', data)\ 触发，父组件监听该事件。
EventBus: 建立一个中央事件总线，实现非父子组件通信。编辑

v-model 原理： v-model 是 v-bind:value 和 v-on:input 的语法糖。编辑

.sync 修饰符： 实现父子组件数据的“双向绑定”，本质是 update:prop 事件的简写。编辑

Computed (计算属性) vs Watch (侦听器)：

Computed: 具有缓存性，依赖项不变不重新计算。支持 getter 和 setter。
Watch: 监听数据变化执行回调，适合异步或开销较大的操作。支持 deep: true 深度监听。

Vuex (Store) 核心：

State: 存放共享数据。
Mutations: 同步修改 State 的唯一方式。
Actions: 处理异步逻辑，提交 Mutation。
Getters: 类似计算属性，对 State 进行加工。

插槽 (Slot)：

基本插槽: <slot></slot>。
具名插槽: <slot name="header"></slot>。
作用域插槽: 子组件传数据给父组件展示。

路由 (Vue Router)：

router-link: 导航链接。
router-view: 路由组件显示出口。
params / query: 路由传参。
重定向与守卫: redirect 配置和 beforeEach 全局守卫。编辑

自定义指令： 使用 Vue.directive 或组件内 directives 定义。常用于操作 DOM（如 v-focus）。

Python 基础

Sun, 05 Jan 2025 16:00:00 GMT

环境与基础概念

Python 是一种解释型、面向对象、动态数据类型的高级编程语言。

变量与命名

Python 中的变量不需要声明类型，直接赋值即可使用。

命名规则：由字母、数字和下划线组成，不能以数字开头。
风格习惯：推荐使用蛇形命名法（snake_case），如 user_name。

标准输入输出

print("Hello Python")           # 输出
name = input("请输入你的名字: ") # 输入（结果始终为字符串）

数据类型

Python 拥有丰富且灵活的数据类型：

基础类型

数字：整数 (int)、浮点数 (float)、复数 (complex)。
布尔：True 和 False。

容器类型

类型	特点	示例
列表 (List)	有序、可变、允许重复	`fruits = ["apple", "banana"]`
元组 (Tuple)	有序、不可变	`coords = (10, 20)`
字典 (Dict)	键值对、无序(3.7 后有序)	`user = {"name": "Gemini", "age": 1}`
集合 (Set)	无序、元素唯一	`unique_ids = {1, 2, 3}`

控制流程

条件判断

Python 使用缩进来表示代码块，这在其他语言中通常使用花括号 {}。

score = 85
if score >= 90:
    print("优秀")
elif score >= 60:
    print("及格")
else:
    print("不及格")

循环结构

for 循环：遍历序列。
while 循环：条件满足时重复执行。

# 遍历 0 到 4
for i in range(5):
    print(i)

# 遍历列表
for item in ["A", "B", "C"]:
    print(item)

函数与模块

定义函数

使用 def 关键字定义函数。

def add_numbers(a, b=10):  # b 为默认参数
    """计算两数之和"""
    return a + b

result = add_numbers(5)    # 返回 15

模块导入

Python 的强大之处在于其丰富的库。

import math
print(math.sqrt(16))      # 输出 4.0

from datetime import datetime
print(datetime.now())     # 输出当前时间

异常处理与文件操作

异常处理

防止程序因为小错误直接崩溃。

try:
    num = 10 / 0
except ZeroDivisionError:
    print("错误：除数不能为零")
finally:
    print("操作完成")

文件读写

使用 with 语句可以自动关闭文件，防止内存泄露。

# 写入文件
with open("test.txt", "w", encoding="utf-8") as f:
    f.write("Python 基础学习")

# 读取文件
with open("test.txt", "r", encoding="utf-8") as f:
    content = f.read()
    print(content)

学习路线建议

基础阶段：掌握上述语法、列表推导式、装饰器。
进阶阶段：面向对象编程 (OOP)、正则表达、多线程/多进程。
应用阶段：
- Web 开发：Django / Flask。
- 数据分析：Pandas / Numpy / Matplotlib。
- 爬虫：Requests / Scrapy。
- 人工智能：PyTorch / TensorFlow。