这里是全站文章的归档入口，下面是按时间倒序排列的全部文章。若想按主题浏览，请从首页的专题分类进入。
崩溃上报与版本遥测：发布后 72 小时的止损阈值
新版本发布后，崩溃率从 0.3% 升到 4%，但你只知道「有用户来信说打不开」。没有版本维度、没有符号文件、没有阈值，止损只能靠猜。本文给出最小采集字段、发布健康三指标、72 小时看板与隐私边界，并附一份可执行的止损清单。
posts
文章归档
PlumePHP 全站文章的归档入口，按时间倒序汇总各专题的技术文章，并提供按主题浏览的专题分类入口。
跨平台构建矩阵：三系统两架构的 CI 成本与发布前置时间
一个人只有一台 Mac，却要交付 macOS、Windows 与 Linux 三个平台、两种架构的安装包。构建矩阵决定了每月花多少 CI 分钟、发布要等多久。本文拆开必须用原生 runner 的组合、签名密钥在 CI 的注入边界，以及从打 tag 到三平台可下载的前置时间。
安装包与更新器：dmg、MSIX、AppImage 与增量更新的验收
用户装上了，不等于装对了。安装路径写错、卸载留残留、更新到一半断电、增量包校验失败，都会让一个能跑的版本变成打不开的应用。本文给出三平台安装包格式的取舍、架构与体积的算法，以及更新器必须通过的六项验收。
《互联网产品的客户端架构·交易、增长与平台化》8.2 积分的加减与过期
积分不是端上可以随便加减的余额，而是一本由发放、抵扣、退回、过期四类流水组成的账。本节说明为什么余额必须从流水重放、过期批次为什么要先到期先出、抵扣失败为什么用退回流水而不是删除，以及多端账本如何按 id 合并，并给出一个可测试的 TypeScript 账本模型。
Windows 签名与 SmartScreen：OV、EV 与信誉积累怎么选
签名有效与 SmartScreen 信誉是两项检查，EV 也不再提供免警告的捷径。本文对比 OV、EV 与托管签名的取得方式，区分发布者身份与文件哈希信誉，梳理安装器、更新器的签名清单，并说明续期、吊销、真实下载测试与用户提示应怎样分别记录。
macOS 签名与公证：Gatekeeper 拦截的六类原因与一次通过清单
在自己的 Mac 上双击安装包一切正常，用户下载后却看到「无法验证开发者」。签名与公证是两道不同的关卡，任何一层漏签、缺时间戳或 entitlements 冲突都会被拦。本文给出六类常见拦截原因、一次通过的检查顺序，以及三台干净机器的验收方法。
分发形态选择：直装、原生商店、包管理器与 Web 版的四条路
同一个售价 49 美元的桌面工具，走官网直装、原生商店、包管理器或 Web 版，到手收入和长期维护工时可能差一倍。本文把四条分发路径拆成四个责任人、一本净收入账和一张选型表，给出「一主一备加退出路径」的判断方法。
《游戏服务端架构·品类、状态与拓扑》11.1 部署单元怎么切
《群岛纪元》把登录、地图、结算和运营写进同一个二进制，一次地图热更回滚连带停掉了登录与充值。本节给出变更频率、伸缩特性、故障隔离、团队所有权和数据边界五个切分维度，比较三款产品的部署单元表，并用 Go 实现的目录模型检查循环依赖、状态归属冲突与有状态共享库。
《互联网产品的 AI 架构·模型接入与能力边界》5.3 流式下的错误与重试语义
从一次首帧后自动重试导致回复重复的事故出发，把流式错误分成首帧前与首帧后两段，给出协议内错误事件与连接断开的分工、可测试的重试决策函数，并用 node --test 验证重试上限、不可重试错误、续传位置与客户端呈现，以及首帧后失败的界面取舍。
品牌延展与退役：第二个产品共用还是另起
第二个产品上线后，有用户问「这是你们做的吗」，因为界面风格和第一个完全不同。品牌延展不是给新产品起个名字，而是决定共用多少：母品牌、子品牌还是独立品牌，token 复用到哪一层，旧产品退役后品牌资产怎么处理。
设计验收：一致性、可访问性与跨平台的一张表
上线两小时后，一位用户发来截图：他用键盘 Tab 了七次，焦点始终停不到保存按钮上。设计验收不是审美评审，而是一张能逐项打勾的表：一致性、对比度、键盘焦点、响应式断点，二十项检查跑完只要三十分钟；跳过它，问题会以 bug 的形式回到线上。
视觉物料：图标、截图、演示图与素材清单
上线前一天，他才发现商店页要五种尺寸的图标、六张截图和一段十五秒的演示，而手里只有一张带测试数据的桌面截图。视觉物料不是发布前临时凑的图，而是一份可以提前列清、按尺寸产出、能反复复用的清单；提前一周准备，比熬夜补图便宜得多。
微文案：按钮、报错与空状态怎么说
按钮上写着「提交」，报错写着「操作失败」，空页面写着「暂无数据」——这三句话让用户多点了三次、多问了两遍、最后关掉了页面。微文案不是文笔问题，是界面的一部分：它决定用户知不知道自己刚做了什么、下一步该做什么。
交互状态：空、加载、错误、成功与无权限
用户看到的「页面坏了」，多数不是 bug，而是没有设计的状态：列表为空时一片空白，保存成功没有任何反馈，没有权限时只显示一行英文报错。一个页面有七种状态，默认态只是其中之一。这一篇给出六态矩阵、加载的三个阈值与状态覆盖率的算法。
首屏与信息架构：一页只回答一个问题
首屏塞进了功能介绍、客户 logo、三个按钮和一段创始人故事，用户却不知道下一步该点哪。首屏只需要回答一个问题：这是什么、给谁、现在做什么。这一篇给出三层信息结构、导航项上限、首屏字数预算与一个五分钟就能跑完的测试。
《互联网产品的客户端架构·交易、增长与平台化》8.1 会员状态与权益展示
会员页最容易把等级、有效期与权益状态混成一个字段：用户看到五条权益，实际只有两条可用。本节把会员快照、权益状态与会员价拆开，说明「可领取」为什么不等于「已拥有」、会员价为什么必须由服务端给出并在结算时重算，并给出一个可测试的 TypeScript 展示模型与到期提醒口径。
设计 token：把颜色、间距、字号写成变量
同一个蓝色在代码里出现了十一次，每次改版都要全局搜索替换，还总漏掉一处。设计 token 不是设计团队的专属工程，而是一个人让界面保持一致的最低成本做法：把颜色、间距、字号写成变量，分清原始值与语义，再控制在三十个以内。
视觉识别的最小系统：一色、一字、一形状
每次改版都换一套颜色，三个月后用户仍然记不住这个产品长什么样。一个人的视觉识别不需要品牌手册，只需要三样东西：一个主色、一个字族、一个形状母题，加一条不能破的对比度底线。改版四次之后他才明白，识别靠的不是设计得多，而是每次都一样。
命名：可搜索、可发音、可注册
产品上线三个月，他发现自己起的名字搜不到：搜索结果第一页全是同名的开源库和一家餐馆。命名不是取一个有感觉的词，而是在可搜索、可发音、可拼写、可注册、可扩展五条约束下找交集，再算清改名的真实成本——名字一换，域名、商店页与外链都要跟着动。
《游戏服务端架构·品类、状态与拓扑》10.3 玩家创造内容的服务端信任模型
UGC 上线后，认证创作者的脚本开始调用经济接口，另一张地图试图直接发放道具。问题不在脚本写错，而在服务端把逻辑也当成了可信输入。本节给出官方、认证创作者、普通玩家三级信任模型，能力白名单、配额与审核强度，以及违规降级、升级条件和平台账本的分工与代价。