小鱼人的博客

人类 AI 发展脉络：从图灵测试到大模型时代

Sun, 26 Jul 2026 00:00:00 GMT

本文面向希望建立「大地图」的读者：不堆砌八卦，而把 问题定义、方法范式、数据与算力条件、工程化拐点 串成一条可读主线。配图为教学向示意图，便于快速建立直觉。

写在前面：AI 不是一条直线#

人们常说「AI 终于爆发了」。更准确的说法是：

问题一直在（如何让机器完成感知、推理、语言、决策）；
范式换了好几次（符号 → 统计 → 深度表示 → 大规模预训练）；
真正撬动曲线的，往往是数据、算力、算法与工程同时成熟。

把历史读成「英雄发明清单」容易失真；把它读成 约束条件下的方法迁移，会更有用。

人类 AI 发展脉络时间轴

图 1：七十年主线时间轴（教学简化）

一、起源：智能能否被计算？（1950–1956）#

1.1 图灵与「机器能否思考」#

1950 年，Alan Turing 在 Computing Machinery and Intelligence 中提出后来俗称的 图灵测试：与其争论「机器有没有心灵」，不如问「机器的语言行为能否在对话中与人难分」。

这一定义非常工程化——它把哲学问题改写成了 可观测的行为判据。尽管后来学界对「通过图灵测试 = 真正智能」有大量批评，但它奠定了现代 AI 讨论的公共语汇。

1.2 达特茅斯会议：AI 作为学科诞生#

1956 年 Dartmouth 研讨会被广泛视为 人工智能学科命名与立项的节点。早期议程雄心勃勃：语言、抽象、自我改进、创造力……都写在愿景里。

早期乐观来自一个强假设：

智能的核心是 符号操作；只要找到正确的表示与规则，机器就能复现理性。

这一假设开启了符号主义的黄金期，也埋下了第一次幻灭的种子。

二、第一次浪潮：感知机、符号主义与寒冬（1957–1970s）#

2.1 连接主义的早产儿：感知机#

Rosenblatt 的 Perceptron 展示了「从样例中学习权重」的可能。它激起媒体热情，也引发严肃争论：单层感知机的表达能力边界是什么？

Minsky 与 Papert 的分析让学界更清醒：没有隐藏层的线性分类器无法处理一类非线性可分问题。这对当时硬件与训练方法条件下的神经网络是沉重打击，连接主义进入漫长低潮。

2.2 符号主义的高光与裂痕#

同一时期，搜索、逻辑证明、早期自然语言与博弈程序在受限领域取得进展。人们逐渐形成一种「高层智能 = 搜索 + 知识 + 启发式」的图景。

但现实很快给出反馈：

承诺	现实约束
通用推理	组合爆炸，搜索空间失控
常识理解	常识极难形式化
鲁棒交互	噪声、歧义、开放世界

于是出现了第一次 AI Winter：资金与预期回落，研究转向更可验证的子问题。

三、专家系统：知识工程的兴衰（约 1980s）#

3.1 把专家经验编成规则#

第二波高潮来自 专家系统：在医学诊断、配置、故障排查等窄域任务上，把专家启发式写成规则库，配合推理引擎给出建议。

它的工程价值真实存在：

可审计（规则可解释）；
可迭代（专家可增补规则）；
在封闭业务里 ROI 明确。

3.2 为什么又冷了？#

核心瓶颈被称为 知识获取瓶颈（knowledge acquisition bottleneck）：

专家自己也说不清全部直觉；
规则数量膨胀后冲突与维护成本爆炸；
离开训练域就脆弱；
与感知（视觉、语音）脱节。

当维护成本超过收益，第二次寒冬接踵而至。教训很尖锐：

可解释的手工知识很珍贵，但很难 scale。

四、统计机器学习：从「写规则」到「估分布」（1990s–2011）#

互联网与数字化把「数据」变成新石油。研究重心从「如何编码知识」转向：

给定特征与标签，如何学习一个泛化良好的函数？

4.1 代表性工具箱#

支持向量机（SVM）：间隔最大化与核方法；
概率图模型：用图结构表达条件独立；
集成树模型：Boosting / Random Forest 在表格数据上极强；
序列与语音早期系统：HMM 等。

4.2 关键变化：评测与可复现#

这一时期形成了现代 ML 文化：

训练集 / 验证集 / 测试集分离；
基准数据集与排行榜；
正则化、偏差-方差权衡成为共同语言。

但也有天花板：特征工程往往决定上限。视觉里手工 SIFT，NLP 里 n-gram 与语言学特征，都高度依赖专家经验。

三条技术主线对比

图 2：符号主义 / 统计学习 / 深度学习——三条主线对照

五、深度学习革命：表示学习重回舞台（2012–2016）#

5.1 ImageNet 时刻#

2012 年，深度卷积网络在 ImageNet 上取得突破性优势，被广泛视为 深度学习进入主舞台 的信号。关键不只是「多层」，而是：

GPU 使大规模矩阵运算可行；
大规模标注数据出现；
更好的初始化、非线性、正则与优化实践。

CNN 证明：层次化特征可以自动学习——底层边缘，中层部件，高层语义。

5.2 序列智能：从 RNN/LSTM 到机器翻译#

语音识别与神经机器翻译迅速跟进。LSTM/GRU 缓解了长程依赖训练困难，seq2seq 与 attention 雏形让「编码器-解码器」成为标准范式。

此时行业形成共识：

在感知与序列任务上，端到端深度模型开始系统性超过传统流水线。

但 RNN 仍受限于逐步计算与长程信息压缩；真正的结构革命还在后面。

六、Transformer 与大模型时代（2017–今）#

6.1 Attention Is All You Need#

2017 年 Transformer 提出后，核心思想可概括为：

用 自注意力 让任意位置直接交互；
高度并行，吃得下超大规模数据；
通过堆叠层数扩展表示能力。

它先征服 NLP，再扩展到视觉（ViT）、多模态、语音、甚至部分科学计算场景。

Transformer 简化示意

图 3：Transformer 教学简化图

6.2 预训练范式：先学世界，再学任务#

BERT、GPT 系列等工作把路线推到新阶段：

预训练：在海量无标注/弱标注文本上学习通用表示与生成；
适配：微调、提示学习、指令微调；
对齐：让模型更好遵循人类意图与安全约束（如 SFT、RLHF、各类偏好优化）。

「大模型」不是单一算法名，而是一套 规模法则 + 数据工程 + 后训练 + 产品化 的系统工程。

6.3 从聊天到系统：工具、RAG 与智能体#

当模型具备较强语言与推理接口后，系统形态快速变化：

能力	意义
工具调用	连接搜索、代码执行、API
RAG	用外部知识补长尾与时效
工作流 / 多智能体	把复杂任务拆成可监控步骤
多模态	图文音视统一接口

AI 越来越像 可编排的认知组件，而不只是单次补全的文本生成器。

当代 AI 能力栈

图 4：从基础设施到智能体的能力分层

七、主线之外：不可忽略的支流#

完整图景还应包括（此处点到为止）：

强化学习：从游戏与控制到作为后训练工具；
概率与因果：不只预测相关，还试图回答干预与反事实；
神经符号结合：把可微学习与规则/求解器拼接；
可信 AI：鲁棒性、隐私、公平、可解释、对齐与治理。

历史反复提醒：单一路线很少永久通吃，混合系统会在工程上不断回来。

八、一张表看懂「每次跃迁靠什么」#

阶段	核心假设	关键燃料	典型失败模式
符号 AI	智能=符号推理	专家知识	常识与开放世界
专家系统	领域规则可穷尽	知识工程人力	维护爆炸
统计 ML	数据可估计函数	特征 + 标注	表示瓶颈
深度学习	层次表示可学	GPU + 大数据	数据偏差、脆弱
大模型	规模带来通才接口	算力/数据/工程	幻觉、成本、治理

九、给读者的阅读地图（如何继续深挖）#

若你想建立可操作的知识树，建议按层学习：

问题：感知 / 语言 / 决策

表示：特征 or 端到端

学习：监督 / 自监督 / 强化

系统：数据工程 + 训练 + 推理

对齐与安全

应用：工具 / RAG / Agent

问题：感知 / 语言 / 决策

表示：特征 or 端到端

学习：监督 / 自监督 / 强化

系统：数据工程 + 训练 + 推理

对齐与安全

应用：工具 / RAG / Agent

先懂损失与泛化（过拟合、正则、验证）；
再懂深度网络训练（反向传播、优化器、归一化）；
再懂序列与注意力；
最后才是分布式训练、推理优化与产品化。

跳过前三层直接「追最强模型名」，容易只剩名词。

十、结语：下一次跃迁可能在哪里？#

没有人能精确预言，但可以从历史外推观察点：

数据质量与合成数据能否继续支撑规模；
推理期计算（test-time compute）如何改写能力曲线；
多模态世界模型能否更好连接行动；
可靠性与治理是否成为比刷榜更硬的门槛；
人机协作界面——AI 是否成为默认的认知基础设施。

对个人学习者，最稳的策略不是赌单一路线，而是：

掌握不变的基础（概率、优化、系统、评测），再快速迁移到新架构。

参考与延伸（公开文献线索）#

Turing, Computing Machinery and Intelligence（1950）
Dartmouth AI 提案与早期符号主义综述
专家系统与知识工程教材章节
ImageNet / AlexNet 相关工作（2012 前后）
Vaswani et al., Attention Is All You Need（2017）
预训练语言模型与对齐技术综述（BERT/GPT 路线及后续）

注：本文为科普向历史梳理，重点在结构与因果，不涉及未公开技术细节，也不对特定商业产品做排名背书。

—— 小鱼人

博客上线：小鱼人的角落

Sat, 25 Jul 2026 00:00:00 GMT

你好，这里是 小鱼人 的个人博客。

关于本站#

域名：blog.727221.xyz
主题：Firefly（Astro 静态站）
托管：OpenResty 静态托管
运维：日常维护与技术文档日更

写什么#

以实用为主，例如：

Linux / Docker / 运维笔记
网络与系统相关学习记录
生活随笔

感谢 Firefly / Fuwari 开源作者。

—— 小鱼人

用 systemd timer 替代 cron：更可控的定时任务

Sun, 26 Jul 2026 00:00:00 GMT

定时任务几乎是每台服务器的标配：备份、清理、同步、拉取证书。多数人第一反应是 crontab -e，写一行就走人。cron 确实简单，但当任务变多、出错、需要排查时，它的短板会集中暴露——脚本执行环境和交互式 shell 不同、输出被邮件吞掉、任务重叠执行、机器关机期间的计划直接丢失。

systemd 已经是主流发行版的 init 系统，它自带的 timer 单元可以完整替代 cron，并且把定时任务纳入统一的服务管理与日志体系。本文记录一套可直接套用的写法。

与 cron 对比#

维度	cron	systemd timer
配置形式	单行表达式	两个单元文件（`.service` + `.timer`）
日志	默认发邮件，常常无人查看	统一进 journal，`journalctl -u` 直接看
执行环境	极简 PATH，与登录 shell 不同	显式声明，行为可预期
错过的计划	关机期间直接丢失	`Persistent=true` 开机后补跑
任务重叠	上次没跑完也会再起一个	同一 service 天然串行，不会重入
随机延迟	需要自己 `sleep $RANDOM`	`RandomizedDelaySec=` 一行搞定
资源限制	无	可用 cgroup 限制 CPU / 内存
依赖关系	无	可声明 `After=`、`Requires=`
手动触发	只能手工执行脚本	`systemctl start xxx.service`
上次/下次执行	需自行记录	`systemctl list-timers` 一览

代价是配置变啰嗦了：一件事要写两个文件。换来的是可观测性和确定性，任务一多就很划算。

一个完整示例#

假设需要每天凌晨做一次备份脚本。先写 service 单元，描述「做什么」：

/etc/systemd/system/backup.service展开收起

1
[Unit]
2
Description=Daily backup job
3
After=network-online.target
4
Wants=network-online.target
5

6
[Service]
7
Type=oneshot
8
User=backup
9
Group=backup
10
Environment="LANG=C.UTF-8"
11
WorkingDirectory=/srv/backup
12
ExecStart=/usr/local/bin/backup.sh
13
TimeoutStartSec=30min
14

15
# 简单加固
16
PrivateTmp=true
17
ProtectSystem=strict
18
ProtectHome=true
19
NoNewPrivileges=true
20
ReadWritePaths=/srv/backup

展开收起

注意 Type=oneshot：跑完就退出，不是常驻服务。没有 [Install] 段是刻意的，这个 service 不需要开机自启，由 timer 拉起。

再写 timer 单元，描述「什么时候做」：

/etc/systemd/system/backup.timer

1
[Unit]
2
Description=Run backup daily
3

4
[Timer]
5
OnCalendar=*-*-* 03:30:00
6
Persistent=true
7
RandomizedDelaySec=15min
8
AccuracySec=1min
9
Unit=backup.service
10

11
[Install]
12
WantedBy=timers.target

两个文件同名（backup），systemd 会自动关联，Unit= 其实可省略，写出来更直白。

启用：

Terminal window

1
sudo systemctl daemon-reload
2
sudo systemctl enable --now backup.timer
3

4
# 看下次触发时间
5
systemctl list-timers backup.timer
6

7
# 不等定时，立刻手动跑一次验证
8
sudo systemctl start backup.service
9

10
# 看这次跑的输出
11
journalctl -u backup.service -n 50 --no-pager

OnCalendar 的语法比 cron 表达式易读得多，写完可以用 systemd-analyze 校验：

Terminal window

1
systemd-analyze calendar "Mon..Fri 09:00"
2
systemd-analyze calendar "*-*-01 04:00:00"
3
systemd-analyze calendar "hourly"

它会打印规范化结果和下一次触发时间，比在脑子里推算 0 3 * * * 靠谱。

除了绝对时间，还有相对触发方式，适合「开机后 10 分钟跑一次，之后每 6 小时一次」这类需求：

1
[Timer]
2
OnBootSec=10min
3
OnUnitActiveSec=6h

常见坑#

1. 改了单元文件没有 daemon-reload。 systemd 读的是缓存后的配置，改完必须 systemctl daemon-reload，否则你会对着「明明改了却没生效」发呆。

2. enable 错了对象。 要 enable 的是 .timer 而不是 .service。启用 service 意味着开机就跑一次，和你的意图无关。

3. 以为 service 里能用 shell 语法。 ExecStart= 不经过 shell，管道、重定向、通配符、&& 都不会被解析。需要这些就调用脚本文件，或者显式写成：

1
ExecStart=/bin/bash -c 'foo | bar > /var/log/out.log'

4. PATH 和环境变量与登录 shell 不同。 service 里的 PATH 很短，node、pnpm、docker 之类常因为版本管理器装在用户目录而找不到。稳妥做法是在 ExecStart 里写绝对路径，或用 Environment= 显式补全。

5. Persistent=true 的补跑行为要想清楚。 它会在开机后立即补执行错过的任务。对备份、证书续期是好事；对「每天推送一次通知」类任务，可能在开机瞬间一次性触发一堆，需要评估。

6. 相对时间的基准容易记混。 OnUnitActiveSec= 从上次启动时刻算起，OnUnitInactiveSec= 从上次结束时刻算起。任务耗时长时两者差别明显。

7. 忘了任务超时。 Type=oneshot 默认会等任务结束，卡住的进程可能一直挂着。用 TimeoutStartSec= 给个上限，超时自动杀掉，不至于挡住下一轮。

8. 用户级 timer 的存活问题。 放在 ~/.config/systemd/user/ 下的 timer 由 systemctl --user 管理，用户退出登录后默认会被清掉。需要常驻就执行一次 loginctl enable-linger <用户名>。

9. 集群里所有机器同一秒触发。 多台机器同时拉取同一个上游，容易把对方打崩。RandomizedDelaySec= 把触发点打散，比在脚本里 sleep $((RANDOM % 300)) 干净得多。

排查手册#

几条日常够用的命令：

Terminal window

1
# 所有 timer 的上次/下次执行
2
systemctl list-timers --all
3

4
# 某个任务的历史日志（含退出码）
5
journalctl -u backup.service --since "3 days ago"
6

7
# 实时跟踪
8
journalctl -u backup.service -f
9

10
# 看单元最终生效的完整配置（含 drop-in 覆盖）
11
systemctl cat backup.service
12
systemd-analyze verify /etc/systemd/system/backup.service

systemctl status backup.service 会显示上次退出码，脚本里记得让失败路径 exit 非零，否则 systemd 认为一切正常。

小结#

cron 依然适合「一行搞定、跑挂了也无所谓」的临时任务。但只要任务需要被观测、需要处理错过与重叠、需要限制资源或声明依赖，systemd timer 的多写几行就非常值得。

迁移路径也不激进：不必一次性清空 crontab，可以先把最关键、最容易出问题的那几个任务改成 timer，跑上两周看看日志是否更好排查，再决定要不要继续推进。

—— 小鱼人

OpenResty 静态站：缓存策略与安全响应头落地

Sun, 26 Jul 2026 00:00:00 GMT

静态博客构建一次、到处分发，表面上很省事；真正上线后，瓶颈往往不在「能不能打开」，而在「打开得快不快、缓存对不对、头信息安不安全」。本文以 OpenResty（兼容 Nginx 配置）托管 Astro/Firefly 产物为例，给出一套可直接落地的缓存与安全响应头方案。

目标拆解#

对静态站通常要同时满足：

HTML 可快速更新：发文后用户刷新即见新内容，不靠硬刷新清缓存。
静态资源可长期缓存：_astro/、字体、图片等带 hash 的文件，浏览器尽量本地复用。
安全基线：补齐常见响应头，降低点击劫持、MIME 嗅探、协议降级等风险。
传输更省：开启压缩，对文本资源减体积。

不要把「整站 expires 30d」一刀切——那是踩坑最快的方式。

目录与路由习惯#

Firefly/Astro 构建后常见结构：

1
dist/
2
  index.html
3
  posts/<slug>/index.html
4
  _astro/*.js|*.css   # 文件名含内容 hash
5
  assets/
6
  pagefind/

对应 OpenResty root 指向发布目录（例如 /opt/openresty/www/blog），文章 URL 形如 /posts/<slug>/。

安全响应头（站点级）#

在 server { ... } 内统一加（对错误页也生效时用 always）：

1
server {
2
    listen 443 ssl http2;
3
    server_name blog.example.com;
4
    root /opt/openresty/www/blog;
5

6
    # 基础安全头
7
    add_header X-Content-Type-Options "nosniff" always;
8
    add_header X-Frame-Options "SAMEORIGIN" always;
9
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
10
    add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always;
11
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
12

13
    # 纯静态站可先用较宽松 CSP，再逐步收紧
14
    # add_header Content-Security-Policy "default-src 'self'; img-src 'self' data: https:; style-src 'self' 'unsafe-inline'; script-src 'self';" always;
15

16
    # … ssl、location 等
17
}

展开收起

说明：

HSTS 只在确认全站 HTTPS、无混用 HTTP 子域后再开。
CSP 对带内联脚本/第三方统计的主题容易误伤，建议先在报告模式或分阶段启用。
OpenResty/Nginx 的 add_header 在嵌套 location 里会「覆盖」上层，而不是合并——所以关键头要么只在最内层写全，要么用更现代的 more_set_headers（headers-more 模块）统一管理。

压缩#

1
gzip on;
2
gzip_vary on;
3
gzip_min_length 1024;
4
gzip_comp_level 5;
5
gzip_types text/plain text/css application/javascript application/json application/xml image/svg+xml;
6

7
# 若已编译 brotli 模块
8
# brotli on;
9
# brotli_comp_level 5;
10
# brotli_types text/plain text/css application/javascript application/json application/xml image/svg+xml;

HTML/CSS/JS/JSON/SVG 压缩收益明显；已压缩的 woff2、png、jpg、webp 不必再压。

发布后如何验证#

发文或改配置后，用本地回环 + SNI 验证（端口按你的反代实际调整）：

Terminal window

1
# 看 HTML 是否禁止长期强缓存
2
curl -skI --resolve blog.example.com:443:127.0.0.1 \
3
  https://blog.example.com/posts/some-slug/
4

5
# 看构建资源是否 immutable
6
curl -skI --resolve blog.example.com:443:127.0.0.1 \
7
  https://blog.example.com/_astro/some-file.hash.js

期望：

文章页：HTTP/2 200，Cache-Control 含 max-age=0 或短 max-age。
_astro 资源：max-age=31536000 且最好带 immutable。
安全头：至少能看到 X-Content-Type-Options、X-Frame-Options 或你配置的等价头。

再配合一次真实浏览器：DevTools → Network，确认二次访问 HTML 走 304/协商，hash 资源走 disk cache。

和构建流水线的配合#

静态站正确缓存的前提是 构建产物文件名稳定且内容寻址：

用主题/框架自带的 hash 资源命名（Astro 默认如此）。
发布采用「整目录替换」而不是零散覆盖，避免半新半旧。
HTML 不长期强缓存；若用 CDN，发布脚本里加对应 URL 的 purge。
构建机 OOM 时优先限制并行、提高 swap 或 NODE_OPTIONS=--max-old-space-size=...，而不是关掉 pagefind/字体子集化后留下残缺产物。

示例发布节奏（概念上）：

1
pnpm build  →  清空 www  →  拷贝 dist  →  （可选）CDN purge  →  curl 抽检首页与最新文章

常见坑#

现象	可能原因	处理
发文后仍看到旧文	HTML 被 `expires 30d` 或 CDN 强缓存	HTML 改为 revalidate；purge CDN
改了 CSS 不生效	自定义 CSS 无 hash 且长缓存	文件名加版本号，或缩短 max-age
安全头「配了但没有」	子 location 的 `add_header` 覆盖了父级	在返回 200 的那个 location 写全，或用 headers-more
仅首字节快、整页慢	未开 HTTP/2、未压 JS、字体阻塞	开 http2、压缩、`font-display: swap`
本地 curl 200、外网 404	反代 root/try_files 与发布目录不一致	对齐 `root` 与实际 `dist` 拷贝路径

最小可复制清单#

root 指向当前发布目录；try_files 支持 Astro 的目录型 URL。
/_astro/、带 hash 的 assets：max-age=31536000, immutable。
HTML 与页面路径：max-age=0, must-revalidate（或 CDN 短 TTL + purge）。
站点级安全头 +（确认 HTTPS 后）HSTS。
gzip/brotli 覆盖文本类型。
每次发布后用 curl -I 抽检一篇新文章和一个 _astro 资源。

小结#

OpenResty 托管静态博客，性能与正确性主要来自 分层缓存 和 发布可观测，而不是堆一堆模糊的 expires。HTML 求「新」，hash 资源求「稳」，安全头求「全站一致」。把这三件事写进配置和发布脚本，日更站点就能在「当天可见」和「重复访问足够快」之间取得平衡。

若你的主题还有 service worker 或 PWA，需要额外审查 precache 列表，避免把 HTML 永久钉在客户端——那是另一层「缓存」，比 Nginx 更难排查。纯静态 + 上述头策略，对个人技术博客通常已经够用。

小鱼人的博客

人类 AI 发展脉络：从图灵测试到大模型时代

写在前面：AI 不是一条直线#

一、起源：智能能否被计算？（1950–1956）#

1.1 图灵与「机器能否思考」#

1.2 达特茅斯会议：AI 作为学科诞生#

二、第一次浪潮：感知机、符号主义与寒冬（1957–1970s）#

2.1 连接主义的早产儿：感知机#

2.2 符号主义的高光与裂痕#

三、专家系统：知识工程的兴衰（约 1980s）#

3.1 把专家经验编成规则#

3.2 为什么又冷了？#

四、统计机器学习：从「写规则」到「估分布」（1990s–2011）#

4.1 代表性工具箱#

4.2 关键变化：评测与可复现#

五、深度学习革命：表示学习重回舞台（2012–2016）#

5.1 ImageNet 时刻#

5.2 序列智能：从 RNN/LSTM 到机器翻译#

六、Transformer 与大模型时代（2017–今）#

6.1 Attention Is All You Need#

6.2 预训练范式：先学世界，再学任务#

6.3 从聊天到系统：工具、RAG 与智能体#

七、主线之外：不可忽略的支流#

八、一张表看懂「每次跃迁靠什么」#

九、给读者的阅读地图（如何继续深挖）#

十、结语：下一次跃迁可能在哪里？#

参考与延伸（公开文献线索）#

博客上线：小鱼人的角落

关于本站#

写什么#

用 systemd timer 替代 cron：更可控的定时任务

与 cron 对比#

一个完整示例#

常见坑#

排查手册#

小结#

OpenResty 静态站：缓存策略与安全响应头落地

目标拆解#

目录与路由习惯#

推荐 location 分层#

1. HTML：短缓存或禁用强缓存#

2. 带 hash 的构建产物：一年缓存 + immutable#

3. 字体与图片#

安全响应头（站点级）#

压缩#

发布后如何验证#

和构建流水线的配合#

常见坑#

最小可复制清单#

小结#