这里是全站文章的归档入口，下面是按时间倒序排列的全部文章。若想按主题浏览，请从首页的专题分类进入。
《互联网产品的 AI 架构·模型接入与能力边界》4.1 路由的五个维度
从「回声」的三类 AI 调用出发，把多模型路由拆成任务、租户、区域、成本与健康五个维度，说明哪些事实该由业务侧声明、哪些必须由网关实时掌握，并用可运行的 TypeScript 规划器与审计函数把维度主权固定下来，最后复盘一次便宜模型把长文摘要截断的事故。
posts
文章归档
PlumePHP 全站文章的归档入口，按时间倒序汇总各专题的技术文章，并提供按主题浏览的专题分类入口。
《Java 编程实战》15.1 测试金字塔：单元、集成与端到端
libraryd 有 33 个测试，但把领域、仓储、HTTP 和端到端混在一起跑，会让失败定位和反馈速度一起变差。本节按模块划出四层测试，说明每层该依赖什么、不该依赖什么，并用真实的测试数量、耗时与配比解释为什么端到端只保留两个主链路用例。
《游戏服务端架构·品类、状态与拓扑》7.3 观战、回放与赛事架构
从《裂隙战场》一场赛事回放对不上比分讲起，比较事件日志与快照两种回放载体，讨论观战延迟、回放体积、可验证性与赛事隔离，说明比赛服、观战服、数据导出和断线重开如何分工，并给出 internal/replay 的关键帧、重建校验、体积估算与边界处理实现。
《游戏服务端架构·品类、状态与拓扑》7.2 FPS 的专用服、命中判定与延迟补偿
从《裂隙战场》射击玩法一次“我明明在掩体后”的争议讲起，拆开专用服池、tick rate 与带宽预算、服务器回滚窗口和命中判定归属，比较 20/30/60Hz 三档的取舍，说明延迟补偿的公平边界与防“延迟优势”手段，并给出 internal/lagcomp 的环形快照、按时间回滚与射线命中实现。
《游戏服务端架构·品类、状态与拓扑》7.1 MOBA 的房间、tick 与帧同步
从《裂隙战场》5v5 房间一次输入迟到 80ms 导致技能错位讲起，用确定性要求、带宽、断线重连、观战与反作弊五条判据比较帧同步和状态同步，说明选定帧同步后成本如何转移到输入窗口、空帧推进与滚动哈希，并给出 internal/moba 的可测试聚合器、失败模式表与常见错误边界。
第 91–100 天：复盘与判据
以同队列转化、成熟用户使用留存和净现金跑道复盘，提供Wilson可运行算例、含未知状态的决策矩阵，以及有适用条件的停服公示和收尾清单。
第 81–90 天：反馈分诊与第一次收费
反馈不是需求清单：23 条意见里往往只有两三条真正阻断使用。本篇给出四类反馈的判据、六列分诊表、优先级公式的边界、三种拒绝话术、四条从免费到付费的路径、定价页五个元素与三个锚点，并用 10 人 2 付费的算例说明小样本为什么只能当方向。
《后端架构设计·高性能与高可用》附录 C 故障演练检查表
卷二的故障演练检查表：演练前必须确认的十项准备、影响范围与审批、观测空跑与数据重置、八个可重复注入的故障场景、每个场景的预期信号与通过标准、中止与回滚条件、执行记录表、时间线复盘与改进项跟踪、演练角色分工、七条禁止事项，以及可以打印的一页清单。
第 71–80 天：发布与第一周
按统一日历组织第68天预热、第71天发布与首周承接，按损害处置事故，用同队列人数记录漏斗，并以成本和证据比较增长实验。
第 61–70 天：上线前的十五件事
将上线十五项分为适用法律安全硬门槛、交易路径和可后置体验，按支付通道规则区分沙箱与生产验收，给出逐项30小时基线及退款状态记录。
《游戏服务端架构·品类、状态与拓扑》6.3 经济系统与随机数的可信边界
从《群岛纪元》一次掉落表热更导致历史抽奖无法复盘讲起，区分服务端权威随机、种子提交-揭示与客户端可验证三种做法；给出掉落表版本固定、HMAC 派生随机数、双分录账本与对账边界的 Go 实现，并用 7 组测试覆盖提交篡改、权重边界、版本回溯与账本非法分录。
《后端架构设计·高性能与高可用》附录 B 性能指标速查
卷二的性能指标速查：延迟分位数与直方图合并、吞吐与完成率、利特尔法则与排队深度、错误率与可用性、错误预算与 SLO 写法、资源饱和度、缓存与治理指标、指标采集的三种方式、常用公式与单位换算、标签与基数控制，以及十种常见误读和一套最小仪表盘配置。
《互联网产品的客户端架构·交易、增长与平台化》4.3 待支付超时与取消
待支付倒计时不该由本地时长递减，而要以服务端 expiresAt 为准，并用服务端时间校正本地时钟。本节讨论切后台、改系统时间、临期取消与支付回调竞争，给出一个可用假时钟验证的 TypeScript 倒计时模块、竞争裁决函数与真实测试运行输出。
第 51–60 天：十人封闭测试
用45分钟任务脚本观察主路径、边界和恢复，给出13小时执行整理预算，按版本保留补测队列、样本局限及数据保护，并以损害和证据决定放行。
第 31–50 天：主路径 MVP 的范围
以托管SaaS为例拆解主路径、范围与120小时需求估算，按本地工具、扩展和人工服务裁剪，并补用户间授权、订单幂等、日志和恢复的最低验收。
《后端架构设计·高性能与高可用》附录 A 压测工具与脚本
卷二使用的压测工具与脚本速查：为什么自带 loadgen、开环与闭环的参数和输出字段、固定场景 P1/P2 的数据准备、流量回放的脱敏与到达过程拟合、延迟口径与采样显著性、结果 JSON 的最小字段、一次真实运行记录，以及压测前后必须检查的十二条事项。
第 21–30 天：手工跑通一次交付
用手工交付验证结果需求，分开现金贡献与自有时间经济差额，记录免费/低价/全价三单，区分流程问题与技术限制，并给出自动化投入和数据处理边界。
第 11–20 天：十次对话
用40分钟访谈与九字段记录挑战需求假设，分开使用者、付款人与决策者，统一问题投入和成交状态，并按实际工时调整取样与后续实验。
第 1–10 天：选题与付费证据
用问题投入A/B/C与本方案成交状态两条轴筛选选题，核对评论来源、切换成本、法律硬门槛及商业风险，给出有限工时下的证据表与验收方法。
「1」是什么：四个里程碑与一张 100 天账本
把0→1拆成演示、使用、本方案成交和使用留存四类证据，给出统一的100天日历、20/40小时两档预算、现金净消耗与成熟队列观察方法。