经典工程智慧：AI 之外不会过时的底子功夫

一句话总纲：架构看收益、接口守规范、排障讲证据链、安全不信肉眼、表达先讲 Why。
这些东西在 LLM 时代不但没贬值，反而更值钱——Agent 生成代码的速度越快，对人的”判断力”要求就越高。

一、耗子叔的架构原则（含因果解读）

出处：陈皓《我做系统架构的一些原则》（2021-12）。原文 11 条，这里按”取舍逻辑”重组为四组。

1.1 先问收益，再谈技术

结论：架构只有三种收益——让团队并行更快、让系统更稳（SLA）、让成本更低（尤其人力成本）。三者都不沾，就是为技术而技术。

因果链：人力成本 = 慢 + 贵 + human error。一个需要”更多人来维护”的架构设计，无论技术多先进，都是失败的——它把最贵的资源变成了负债。所以评审架构时第一个问题不是”用了什么”，而是”省了什么”。

由此派生两条视角原则：

以服务和 API 为视角，而不是以资源和技术为视角。 分布式演进之后，很多组件（服务治理、k8s 健康检查）已经分不清是 Dev 还是 Ops，这正是 DevOps 合并的根因。局部调优救不了整体，就像大城市交通不能靠拓宽某条路解决，只能自顶向下统一规划——统一的规划需要统一的视角，这个视角就是”对外暴露的服务和 API”。
小心 X-Y 问题，追问原始需求。 用户想解决 X，自以为 Y 能解，于是来问你 Y 怎么搞。耗子叔的案例：客户要”大数据流式处理”，追问后发现真问题是一个慢函数拖垮了有状态服务，做个性能调优就够了。接需求先问”你原本要解决什么”，能省掉一整套错误的系统。

1.2 选型逻辑：成熟 > 熟悉，完备 > 性能

结论：选全球主流的工业化技术栈，而不是自己熟悉或本地流行的；先保完备性，性能问题后面总有解。

因果链拆开看：

为什么不选”自己熟悉的”？ 架构被技术负责人的个人喜好绑架，是耗子叔见过最多的病。0→1 阶段用什么都行；1→10、10→100 时系统变复杂、团队变大，玩具技术就撑不住了（京东从 .NET 迁 Java、淘宝从 PHP 迁 Java，迁移极其痛苦）。
为什么不魔改、不造轮子？ 不是技术不行，而是收益结构变了：这个时代的最大红利来自与整个技术社区的融合。魔改开源的公司，最后往往”改着改着发明了另一个 kubernetes”，短期爽、长期被主流取代。
为什么完备性 > 性能？ 典型反例：为性能上来就用 NoSQL/Redis 当主存储，后来要做关联查询，只能靠冗余数据飞线，又维护不好一致性，数据错乱丢失。原则是”先紧后松”——ACID 关系库为主、NoSQL 作补充；紧了可以慢慢松，松了就再也紧不回来。性能的解法有很多，完备性丢了就没解。

1.3 控制逻辑收口 + 标准规范

结论：程序 = 业务逻辑 + 控制逻辑；控制逻辑（流量、服务治理、监控、部署、中间件）必须由专业团队统一收口，且全公司遵循标准规范。

为什么要收口？控制逻辑技术深、门槛高、跟业务无关，散落到各业务团队只会做出 N 套不一致的烂实现。收口的五个面：流量（网关/Mesh）、服务治理（发现/熔断/限流）、监控数据（日志/指标/链路必须汇到一处才能关联出信息）、资源调度（容器化）、中间件（共享资源池）。

为什么要标准？没有标准就没有抽象，没有抽象一定出乱子。 反面典型：HTTP 无论成败都返回 200、body 里再区分 error——代价是监控系统必须拆开每个包才知道是否出错，且分不清 4xx（调用方错，重试无意义）和 5xx（服务方错，才值得重试/熔断），整套控制系统直接失能。还有公司拿身份证号当跨系统用户 ID 同步，隐私风险裸奔。

1.4 面对技术债与新技术的姿态

不迁就技术债：长痛不如短痛。 债务会滚利息，最终变成高利贷（典型病态模式：系统烂了不修，在旁边再建一个系统”看着它”）。可行策略：建设无债的”新城区”，用**防腐层（Anti-Corruption Layer）**隔离老系统，不让债务侵入新区。
靠数据和学习做决定，不靠经验。 技术手段都有适用场景和 trade-off，确诊要靠诊断数据，如同医生看病。”凭以往经验做决定的那一天，你就停止成长了。”
激进胜于保守。 积极拥抱会改变未来的技术（他当年快速跟进 Docker/Go），但不是见新就上（对区块链保持学习不重仓）。逻辑：进步来自探索，探索有代价但收益更大；”实用主义、够用就行”的公司第一天就在负债，最后还是会被逼着换技术。

✅ 架构评审检查清单（口诀：收益、视角、选型、完备、标准、收口、还债、问数据、追 X）

这个设计降低了哪项成本、提升了哪个 SLA、加速了哪个团队？说不出来就砍。
是站在服务/API 视角，还是某个团队的资源视角？
技术栈是全球主流吗？有没有魔改/自研轮子？谁来养？
数据模型完备吗？有没有为性能提前放弃 ACID？
错误码、命名、日志、配置、版本有统一规范吗？软件版本一年 review 一次了吗？
控制逻辑（治理/监控/部署）收口了吗，还是散在各业务团队？
方案是在迁就旧债，还是在还债？防腐层画了吗？
决策依据是诊断数据 + 多方案 Pros/Cons，还是某人的过往经验？
用户提的是 X 还是 Y？原始需求追问过吗？

二、API 设计的经典反模式：”REST 全用 POST”

出处：陈皓《”一把梭：REST API 全用 POST”》（2022-02）。起因是 V2EX 热帖：有人所有接口全定义成 POST，理由是”HTTPS 下 POST 更安全、省沟通、早回家”。

2.1 为什么这是反模式：动词属于控制逻辑

关键洞察：几乎所有网络协议都分协议头（控制逻辑）和协议体（业务逻辑），HTTP 动词在协议头里，服务的是整条链路上的基础设施，不是给你的业务代码看的。 把全部语义塞进 POST，等于把控制信息藏进 body，让所有中间设施变瞎。

具体付出的代价（因果逐条对应）：

丢掉的机制	后果
幂等性标记（GET/PUT/DELETE 幂等，POST 不幂等）	远程调用超时后不知能否重试。转账类请求贸然重试 = 重复转账；不敢重试 = 可用性下降。全 POST 后重试策略完全失控
缓存	CDN/网关无法对读操作做缓存
流控/路由	无法按读写分流（读写分离路由）、无法对读写设不同限频
权限/审计	失去按方法粒度的权限控制
监控/压测	读写混在一起，性能分析和压力测试没法做

对三个流行论调的回击：

“POST 更安全”——不成立。 HTTPS 下 URL PATH 同样封装在加密协议头里；而 CSRF 这一最常见攻击恰恰主要针对 POST。真正的安全靠加密、URL 签名、HMAC 认证，与动词无关。
“省沟通”——恰恰相反。 规范和标准本身就是人类协作降本的工具；山寨 API 逼得使用方不断来问你，短期省的时间以技术债形式加倍偿还。
“API 不怕过早优化”——因为 API 是契约。 一旦被使用就极难变更（如同数据库 Schema），所以必须一开始就好好设计。

2.2 顺带记住的正面规范

复杂查询四件套：sort（排序）、filter（过滤表达式）、search（搜索）、分页（page/per_page；大数据量或高频更新场景改用 max_id / published_before 的绝对位置分页，避免性能和数据偏移问题）。
动词不要机械对应 CRUD，要按业务语义：/login 是新增 session，用 POST；/logout 用 DELETE。
复杂查询理论上尽量 GET（ES 官方也这么推荐），类库不支持 GET 带 body 时才退到 POST。

🚫 API 设计红线（评审时直接对照）

读操作必须可缓存、可重试——至少做到 GET 读 / POST 写的”最低配读写分离”。
状态码语义不许破坏：2xx 成功、4xx 调用方错、5xx 服务方错；禁止”永远 200”。
非幂等接口（POST/PATCH）必须显式设计重试与去重策略（幂等键）。
API 契约变更视同 Schema 变更：设计期对照 Microsoft / Paypal / Google API Guidelines。
分页必须是默认行为，禁止无界返回。

耗子叔的收尾值得抄在工位上：“你的工作给你权力，你的行为才给你尊重。” 遵循规范只是”正常”，把正常叫”优雅”，说明标准已经低到尘埃里了。

三、一次生产问题的根因分析范本（ETCD 内存暴涨）

出处：陈皓《ETCD 的内存问题》（2022-05）。这篇的价值不在结论，而在完整的排障证据链——可以当 RCA 模板背下来。

3.1 案情与根因链

现象：用户在 Easegress（内嵌 etcd 的 API 网关）里配了 1000+ 条 pipeline，什么请求都不发，内存从 400MB 一路涨到 10GB+ 且不回落。

排查路径（注意每一步的方法论）：

先定位归属：内存基本全在 etcd——但写入的 key 总量估算不超过 10MB，量级严重对不上。
先怀疑已知 bug：上游 issue 搜内存泄漏——3.2/3.3 有但已修复，当前用 3.5。排除。
转向怀疑自己误用：沉下心花两天把 etcd 的设计读一遍（而不是继续瞎试参数）。
找到根因：etcd 的 Raft Log 为了帮 follower 追数据，在内存里 hardcode 保留最近 5000 条请求（DefaultSnapshotCatchUpEntries = 5000）。Easegress 把 1000 条 pipeline 的统计数据合并写进同一个 key，形成约 2MB 的大 value → 5000 × 2MB ≈ 10GB。完整因果链：大 value 反复更新 → 每次更新都进内存 Raft Log → 固定保留 5000 条 → 内存被放大 5000 倍。
修复：不改 etcd，改用法——把大 key 拆成多个小 key，数据总量不变，Raft Log 单条从 2MB 降到 1KB，内存从 10GB 降到 500MB。

3.2 顺手学到的 etcd 内存账本

Raft Log：内存态，至少 5000 条最新请求，大 value 的第一杀手。
B-tree 索引：每对 KV 在内存建索引，开销与 key 长度、历史版本数正相关。
mmap：boltdb 映射进虚拟内存，db-size 越大内存越大（用 compact + defrag 压缩）。
Watcher：watch 数和连接数多了同样堆内存。
还有一层语言运行时：Go 1.12 的 MADV_FREE 回收策略使 RSS 不下降，1.16 改回 MADV_DONTNEED——“内存不回落”有时是观测假象，先确认回收语义再喊泄漏。

3.3 姊妹范本：TIME_WAIT（《从一次经历谈 TIME_WAIT 的那些事》2022-07）

探活工具 EaseProbe 每次探测都新建并关闭连接 → 主动关闭方堆积 TIME_WAIT → 客户端本地端口（默认仅约 28K 个）耗尽。处理思路同样是”先懂协议再动手”：TIME_WAIT 等 2MSL 是防止延迟报文串进新连接 + 确保对端收到最后的 ACK（两将军问题没有完美解），是协议完整性的一部分，不要粗暴妥协。结论口诀：

服务端：永远别设 SO_LINGER(0)、别用 tcp_tw_recycle（已从内核删除）；设好 KeepAlive，让客户端主动断链。
客户端（出站方）：tcp_tw_reuse 和 SO_LINGER(0) 可用——EaseProbe 用 SetLinger(0) 走 RST 关闭，彻底消灭 TIME_WAIT。

✅ RCA 方法论清单（从这两篇提炼）

量级对账：现象数值和理论估算差几个数量级？差距本身就是线索。
先查上游已知问题，再怀疑自己误用——大内存问题多半不是”泄漏”而是”设计放大”。
卡住时去读组件的设计文档/源码，两天的”笨功夫”比两周的乱试参数快。
修复优先改自己的用法，而不是 fork 上游。
把根因写成因果链（A→B→C→放大系数），并沉淀成使用规约（如”避免大 key/value”）。

四、安全与工程伦理

4.1 源代码特洛伊木马：你的眼睛会骗你

出处：陈皓《源代码特洛伊木马攻击》（2021-11，对应 CVE-2021-42574 “Trojan Source”）。

三种”肉眼审查必败”的攻击：

双向文本控制符（BiDi）：用 U+202E/U+202D 等 Unicode 控制符重排代码的”显示顺序”，你看到的字符串边界和编译器执行的完全是两码事（Go 示例里看似正常的 "Hello, World!", 0x01 实际是另一段逻辑）。
不可见字符：如 \u3164 做变量名，凭空多出一个看不见的 HTTP 参数，构成远程命令执行后门。
同形字符：ǃ（非惊叹号的 Unicode 同形字）冒充 !，if(environmentǃ=ENV_PROD) 变成赋值/永真逻辑，绕过生产环境权限检查，转码也查不出来。

防御结论：代码审查不能只靠人眼，必须靠工具链——开启 GitHub 的 bidirectional Unicode 告警、CI 里加非 ASCII/控制字符扫描、编辑器显示控制字符。对 AI 时代的额外提醒：Agent 大量引入外部代码片段时，这类攻击面在变大。

4.2 身份认证的骨架：从密码到 mTLS

出处：陈皓《网络数字身份认证术》（2022-01）。一条递进链讲清”为什么需要每一层”：

密码只能存在于”用户 ↔ 权威机构”之间——因为验证方必须持有秘密，秘密不可扩散。加固靠 2FA/MFA。生物特征是糟糕的身份凭证：易伪造，且不可吊销不可重置。
非对称密钥对解决”不交秘密也能验身份”，但挡不住中间人——公钥本身无法自证归属。
于是需要 CA 证书：可信机构用自己的私钥给”身份+公钥”签名，层层套娃形成证书链，根证书是信任锚。
企业内部/零信任场景升级为 mTLS 双向认证（客户端也出示证书），这是云原生服务间通信的首选。公网不用 mTLS 只是因为给几十亿终端发证书不可运维，不是因为它不好。

口诀：秘密不出门（密码），公钥要签名（证书），内网双向验（mTLS），生物只做辅助因子。

4.3 工程伦理两则

员工监控（《谈谈公司对员工的监控》2022-02）：监控信息安全可以理解，但底线是知情权 + 范围/用途/销毁期限的书面协议（他在 Thomson Reuters 入职时签的就是这种双向法律文件）；没有协议的监控本质是流氓行为。更深一层：员工有一万种方法泄密，真正的护城河是有职业操守的招聘、信息分级管理和让人有归属感的文化——靠监控管理，恰恰暴露了管理无能。
审查与去中心化（《聊聊 nostr 和审查》2023-02）：nostr 用”密钥即身份 + 多 relay 转发”让删号封禁失效，本质是升级版 email 架构。但耗子叔同时给了冷静的另一半：完全消灭审查的终点是垃圾信息的海洋，Spam 治理（黑名单、算法过滤、提高成本）本身就是某种审查。工程启示：任何”绝对自由/绝对管控”的系统设计都不成立，要设计的是制衡机制。

五、存储与 ID 设计的老手艺（廖雪峰）

四篇短文，全是”一次设计错误、终身买单”的领域。

5.1 主键三律（《浅谈数据库主键策略》2016）

主键不可修改——它被所有外键引用，改主键 = 破坏全库数据完整性（多数 Web 应用只有逻辑引用没有外键约束，坏起来更无声）。
业务字段永不做主键——Email 再唯一也会被修改（修改是业务操作，违反第 1 条），还会随外键扩散泄露信息。唯一业务字段加 unique 索引即可。主键应是除唯一标识外零业务含义的独立字段。
自增 ID 的最大问题不是分库难，而是泄露运营数据——竞对每周注册一个账号，ID 相减就是你的真实新增。主键只需唯一，不需连续；不可预测性还是安全属性。

5.2 分布式 ID（《分布式唯一ID生成器》2019）

方案光谱：数据库自增（插入前拿不到 ID）→ 集中式发号器 Redis/ZK（复杂、重依赖，”越复杂的方案越不可靠”）→ Snowflake 类无状态算法（时间戳+机器位+序列号，无网络调用）。廖版改良：53bit = 32bit 秒级时间戳 + 16bit 自增 + 5bit 机器位；序列号用完就”借下一秒”，顺带解决时钟回拨。

为什么是 53 位？JavaScript Number 的整数精度上限就是 53 位。64 位整数传给前端必然丢精度，这就是微博 API 同时返回 id 和 idstr 的原因。——跨语言边界的精度约束，是后端设计必须提前吃进去的隐性契约。

5.3 Profile 与 Auth 分离（《设计一个可扩展的用户登录系统 (1)》2016）

反模式：往 Users 表里为每种第三方登录加三列（weibo_id/token/expires…），加一种登录方式改一次表。正解：登录的本质是认证（Authenticate），Users 表的本质是资料（Profile），两者分离——LocalAuth、OAuth（多家共用一表加 oauth_name 列）、APIAuth 各自成表，靠 user_id 关联。收益：新增登录方式零改动老表、一个用户多种登录并存、Users 表不含任何口令/Token，泄露面最小。

5.4 性能演进的范本（《高性能交易系统设计原理》2020）

交易系统三代演进：全数据库（约 100 单/秒）→ 内存撮合 + 数据库清算（约 1000 单/秒，瓶颈立刻转移到清算，”修了 100 车道的高速，收费站只有几个口”）→ 全内存撮合+清算、单线程无锁模型（10 万单/秒，与 LMAX Disruptor、Redis 同一思想），代价是内存易失，必须自己解决状态可靠恢复。两个通用教训：吞吐由最慢的一环决定；多线程不是性能的同义词，消除锁与 IO 才是。

六、语言演进的正确姿势：Go 泛型一课

出处：陈皓《Go 编程模式：泛型编程》（2021-09，Go 1.17 泛型初体验）。

内容本身：[T any] 声明类型参数、comparable 约束支持 ==、自定义约束接口（如 Sumable 限定数值类型）；用泛型重写 Stack/双向链表和 map/reduce/filter 三大件，替代过去只能靠反射或代码生成的丑陋实现（空栈 top 返回 *T 指针以绕开”值的泛型”缺失）。当时的局限也直说：没有操作符重载、没有统一迭代器、fmt 输出不够泛型。

更值得学的是姿势：新语言特性一落地，就用”标准数据结构 + 函数式三大件 + 一个业务小例子”三步走把它吃透，同时诚实记录边界和不适用场景。这正是他”激进拥抱新技术”原则的示范——快速上手、诚实评估、不神化。

七、前端平台的 2026 新能力速览（张鑫旭）

后端视角只需记住”有这个东西、解决什么问题”，需要时再查。

能力	一句话	后端/Agent 工程师的关联点
CSS 视口/容器单位（dvh、svh/lvh、cqw/cqi 等）	`dvh` 随移动端工具栏收展动态变化，解决 `100vh` 在 iOS 上的经典布局 bug；cq 家族按”容器”而非视口取百分比	做管理后台/Demo 页全屏遮罩用 `100dvh`；逻辑单位 vi/vb 张鑫旭直言”了解即可”
原生 JSON 模块导入（`import x from "./x.json" with { type: "json" }`）	浏览器原生解析 JSON 为冻结（Frozen）对象，摆脱打包工具	要求服务端返回 `Content-Type: application/json`；大文件仍建议 fetch，防止内联膨胀主包
`setHTML()` + Sanitizer API	设置 HTML 时原生 XSS 过滤（默认过滤极狠，需 SanitizerConfig 精调）；`setHTMLUnsafe()` ≈ innerHTML	给”LLM 生成 HTML 再注入页面”的场景提供了平台级消毒层
`Element.startViewTransition()`	视图过渡动画从 document 级下放到任意元素，DOM 变更自动补动画	兼容性未到生产线，了解即可
纯 CSS repeat(–n) 循环	用二进制拆位 + 倍增（快速幂思想）在 CSS 里实现任意次数循环	算法思想有趣：”图灵完备的角落无处不在”

重点展开：智能体就绪度（Agent Readiness）

出处：张鑫旭《AI时代网站智能体无障碍访问开发指南》（2026-07），与 Agent 方向强相关。

核心原则：LLM 读的是干净文本——同一页面 HTML 约 15K token，Markdown 只要约 3K，差距决定”读懂”还是”放弃”。六步法：

robots.txt 放行 AI 爬虫 + Content-Signal: search/ai-input/ai-train 声明内容用途；
根目录放 /llms.txt 精选目录（主流爬虫暂不主动抓，但”人+AI 协作”场景会读，是最高价值流量）；
每页提供同路径 .md 版本（统一 Markdown 数据源双向生成，防内容漂移）；
<link rel="alternate" type="text/markdown"> + HTTP Link 头双路发现；
Accept: text/markdown 内容协商（作者判断这是五年后唯一还活着的手段——它只是 HTTP 的本职工作）+ Vary: Accept，该 406 就 406，不许静默塞 HTML；
文档站按需提供 llms-full.txt（Cloudflare 按产品目录拆分后 token 省 31%、答对提速 66%）。

避坑清单（有对照实验背书的”无效努力”）：自造 meta 标签、ai.txt、HTML 注释提示、”人类/AI 切换按钮”（AI 不点按钮）、按 User-Agent 返回 Markdown（这是 Google 明确惩罚的 cloaking，内容协商才合法）、指望 JSON-LD 被 LLM 读取（主流模型全部无视）。共同病灶：优化了 LLM 根本不读的元数据。 真正有效的是丰富正文可见文本：直接引用（可见性 +43%）、具体统计（+33%）、权威引用（低排名内容 +115%）。

八、技术人的表达与成长

8.1 技术分享的结构模板（陈皓《如何做一个有质量的技术分享》2021-07）

好分享的判据只有两条：保鲜期长、能被大范围传播。结构上是一个心理学模型：

问题 → 方案比较 → 最佳实践总结

先描述问题（Why），让听众带入——直接冲进 What 的分享是填鸭，价值不大；
讲 How 时先立问题模型（框住思考范围），再做多方案比较（有比较才有信服力和参与感）；
必须落到 Best Practice / 方法论，这是听众能带走的收获感。

配套军规：小主题优于大主题（Less is More）、60 分钟以内、备课时先找资深者对齐全貌。他给的 Docker 示例大纲可直接套用：要解决的问题 → 备选方案（Puppet/VM/LXC）→ 为什么 Docker 胜出 → 关键技术（image/cgroup/unionfs/namespace）→ Pros/Cons → 延伸阅读。还有一句要记住：分享是最难的学习方式，收益最大的是讲的人，不是听众。

8.2 协同的本质（陈皓《聊聊团队协同和协同工具》2022-10）

Channel（持久、结构化）vs 拉群（临时起意、用完即忘）——工具形态背后是管理成熟度的差异。
协同的基石是信任：已读回执、不可删改、监控定位，这些功能全是不信任文化的产物。
真正提升生产力的是创作类协同工具（Google Doc、GitHub、Figma——在产出物上直接协作），管理类和聊天类工具只制造”有产出的假象”。开会要有深思熟虑的”议案”（Amazon 式：前 15 分钟安静读文档再讨论）。
给新人的话：”人到了不同的环境就会有不同的认识，找一个好的环境对成长有多重要。”

8.3 独立思考示范：微服务之争（陈皓《是微服务架构不香还是云不香？》2023-05）

Amazon Prime Video “微服务改单体、成本降 90%”刷屏时的冷静拆解：真相是 AWS Step Function 有账户硬限制且按状态转换计费太贵——这是产品选型错误（拿编排服务硬扛大流量数据处理），不是”微服务架构失败”的证据；本质是一次”下 Serverless 云”。顺带给出微服务拆分四原则：不大于限界上下文（Bounded Context）、单一职责高内聚低耦合、强一致/同事务的不拆、与组织架构匹配。

方法论收获：看到刷屏结论，先读原文，再做反事实检验——“如果 Step Function 又便宜又能无限扩展，他们还会改单体吗？”不成立的就不是因果，只是相关。

九、延伸阅读

API 规范原典（耗子叔推荐）：Microsoft REST API Guidelines、Paypal API Design Guidelines、Google API Design Guide
coolshell 关联篇目：《关于高可用的系统》《HTTP API 认证授权术》《分布式系统的事务处理》《一些软件设计的原则》
TIME_WAIT 深入：Vincent Bernat《Coping with the TCP TIME-WAIT state on busy Linux servers》
Trojan Source 论文：《Some Vulnerabilities are Invisible》（trojansource.codes）
微软《Cloud Design Patterns》之 Anti-Corruption Layer（还技术债的”新城区”模式）
LMAX Disruptor：单线程无锁高性能模型的工业实现（印证 5.4 节）
eBPF：coolshell 2022-12 有科普（Linux 可观测性的底层杀器，门槛在系统知识而非工具本身），本篇未展开
llms.txt 提案（Jeremy Howard, fast.ai）与 Cloudflare 检测工具 isitagentready.com / acceptmarkdown.com