这里是全站文章的归档入口，下面是按时间倒序排列的全部文章。若想按主题浏览，请从首页的专题分类进入。
《互联网产品的客户端架构·交易、增长与平台化》13.1 端到端：选品、下单、支付、退款
前十二章分别验证了金额、库存、幂等、支付与退款，但真实事故往往发生在模块交界处。本节用五个窄端口把选品、加购、下单、支付、退款串成一条可断言主线，假实现放在测试侧，断言金额一致、只有一笔订单、未确认支付不退款，并复盘一次「每段都绿、整条链路金额对不上」的问题。
posts
文章归档
PlumePHP 全站文章的归档入口，按时间倒序汇总各专题的技术文章，并提供按主题浏览的专题分类入口。
《互联网产品的 AI 架构·模型接入与能力边界》8.1 端到端延迟预算怎么拆
「回声」智能回复承诺 2 秒，团队却把 2000 毫秒直接当成提供方超时，结果网络、排队与后处理叠加后稳定超时。本节把端到端预算拆成网络、排队、首 token、生成与后处理五段，给出整数毫秒分配、超时传播与审计代码，用 Node 测试逐毫秒验证，并复盘一次余量被当成预算的事故。
《Java 高级编程》4.2 原子类与 CAS：AtomicLong 与 LongAdder 的取舍
8 个线程各增 100 万次，普通 long 只数到 333 万。本节用真实计数实验比较 AtomicLong 与 LongAdder 的吞吐与适用面，手写一遍 CAS 循环，再用 Treiber 栈复现 ABA 并给出 AtomicStampedReference 的修法，最后落到 libraryd 的 LoanCounters 与 LoanMetrics。
《Java 虚拟机原理与性能调优》1.2 建立可复现的实验环境：CPU、堆与固定参数
同一份代码在两个堆大小下会给出不同结论。本节固定 JDK、CPU、堆、GC 与启动参数，用 VM.flags 和 GC.heap_info 实测 256 MB、1 GB、2 GB 与 -Xms≠-Xmx 的差异，验证 ActiveProcessorCount 对 GC/JIT 线程数的影响，并给出 collect.sh。
《后端架构设计·演进与治理》2.1 同步调用与异步事件：组合而不是二选一
从 arch-lab 订单链路的一次超时与重复预占事故切入，把同步调用与异步事件放进一致性、延迟、失败传播、运维复杂度四个维度打分，给出可解释的 Go 决策器与五组订单场景的实测结果，说明何时该选同步、异步或混合，并给出写进评审记录的三条判据。
《Java 高级编程》4.1 可见性与重排序：volatile 与 happens-before
libraryd 的缓存刷新线程写了新值，请求线程却一直读旧的。本节用停止标志与 Dekker litmus 两组可复现实验，量化可见性与重排序，讲清 happens-before 的六条规则，再落到 LifecycleFlag 与 AvailabilityCache 的 volatile 发布写法。
《Java 虚拟机原理与性能调优》1.1 从现象到机制：JVM 研究的四条路径
libraryd 的延迟抬升不能靠猜。本节把「现象→假设→实验→证据→结论」拆成可执行步骤，用 jcmd 的 VM.info、VM.flags、GC.heap_info 真实输出演示字段怎么读，并给出症状到第一工具的对照表与四条研究路径的分工。
《移动游戏产品的架构·客户端与移动运行时》2.2 纯逻辑内核：把玩法从引擎里拆出来
把三消规则从引擎节点、动画回调和全局随机数里拆出来，内核只接收棋盘、输入意图与注入的 Clock/Random，返回可重放的状态迁移与结算。本节给出棋盘生成、级联消除、重力补位与会话过期规则，并说明方舟卡牌战斗如何复用同一套边界，让同一局在 Node 里复现。
《游戏服务端架构·核心系统与契约》3.1 匹配算法与公平性
从《裂隙战场》的排队投诉出发，拆解匹配窗口的放宽顺序、可解释的质量指标和跨区延迟预算；对比竞技、SLG、休闲三款产品的不同取值，分析深夜人口不足时的兜底动作与复盘口径，并给出可运行的 Go 分段队列实现、party 不可拆分约束与表驱动测试。
《后端架构设计·演进与治理》1.3 订单域的一次拆分演练：边界、共享数据与回退
以 arch-lab 订单域把 Order 与 Inventory 拆成两个服务为例，演练共享表读取、同步调用改事件、outbox 幂等消费与回滚开关；用同一套 Go 场景在单体、同步、事件三种形态下对比失败行为，附原始测试输出与可执行的回退判据。
《游戏服务端架构·核心系统与契约》2.3 登录排队、限流与开服洪峰
开服洪峰与日常登录不是同一个问题：总量、斜率与重试放大都不同。排队管理预期，限流保护后端，两者不能互相替代。本节给出令牌桶加租户公平队列、位置与等待估算、超时与去重，比较限流放在边缘、网关或账号服务的代价，并说明如何避免排队、超时、重试、更拥堵的正反馈。
《移动游戏产品的架构·客户端与移动运行时》2.1 表现、玩法、系统、平台四层与依赖方向
四层不是四个文件夹，而是四种能被单独验证的职责：平台层封装设备差异，系统层组织账号、支付与配置，玩法层维护纯状态，表现层只做映射。依赖只能向下，跨层调用必须经过接口；本节把职责、输入输出与典型误用写成可检查的契约，并给出允许矩阵与破例记录方式。
《后端架构设计·演进与治理》1.2 拆分粒度：业务能力、数据所有权与变更频率
从 arch-lab 订单模块的依赖图出发，用 Ca、Ce 与不稳定度 I=Ce/(Ca+Ce) 区分稳定核心和易变边缘，给出业务能力、数据所有权、变更频率三条拆分粒度判据，并实现两向边界评审、共享表与跨边界边预算检查，附可运行 Go 代码与本机原始测试输出。
AI 合规验收：十二项检查、四维评分与一次客户审查演练
合规做没做完，不能靠感觉。本文把前面九篇收成十二项检查与四维评分，用一次模拟客户审查找出四个答不上来的问题，算出 3.26 分与补板后的 3.45 分，并把第一年 290 小时的投入与 3,480 美元的机会成本放在一张表里。
事故与变更：十四次模型升级、三次回归失败与一次四小时故障
AI 产品最容易被忽略的合规动作，是「改了什么」这件事本身。本文用一年十四次模型升级、三次回归失败与一次四点二小时的供应商故障，说明版本怎么固定、门禁怎么设、降级怎么切、三个通知渠道怎么写，并把 61.6 小时的年变更成本算清。
内容与版权：一次相似投诉、四十八小时下架与七个数据来源
AI 生成的内容可能和别人写过的很像，这件事在产品里迟早会被问到。本文用一次相似投诉、二十四小时初判与四十八小时下架、七个数据来源里的两条许可缺口，说明输出归谁、投诉怎么接、下架之后还要做什么，并把一次处理的 3.5 小时算清。
评测证据：一百二十条用例、九条红队问题与一份证据包
客户问「你怎么证明模型改版后没变差」，答「我们一直在测」是不够的。本文用一百二十条评测用例、九条红队问题、十四次模型变更与五份文件组成的证据包，说明一次可复核的评测要有什么，并把 61.6 小时的年回归成本与 12 小时的企业交付算清。
人工复核：每月四百一十次、八点二小时与一条升级路径
「有人复核」和「有人点了发送」是两件事。本文用四条触发条件、每月四百一十次复核与三点三级升级路径，说明复核该看什么、看多久、拒绝之后怎么走，把一年九十八点四小时的复核成本算清，并给出三个判断复核是否真的在发生的信号、复核记录怎么导出。
《游戏服务端架构·核心系统与契约》2.2 网关路由与连接归属
网关只终结连接、认证、路由和限流，不承载玩法。真正的难题是连接归属放在哪：网关本地表、共享存储还是 rendezvous 计算。本节比较三种归属方案的故障代价，给出加权 rendezvous 路由、节点摘除后的重分配与归属令牌校验的可运行实现。
输出责任：三档错误、七件投诉与四条条款边界
AI 输出出错时，问题不是「模型胡说」，而是「谁来决定、谁来承担」。本文用三档错误、七件投诉与四条条款边界，说明事实错、建议错、格式错分别怎么处理，免责声明为什么不能替代控制，并算清一年二十四点五小时的投诉成本、投诉入口该放在哪。