标签频道
避坑清单
该标签下的文章、提问与讨论帖。
«结论先行：联调返工里最阴的一类，不是字段名写错、也不是枚举漏值，而是「单位/量纲」没约定——同一个字段，前端理解成元、后端吐的是分；同一个时间戳，这边按毫秒、那边按秒。它比"字段缺失"更危险，因为每个环节都"看起来对"：接口 200、字段
43 条验收标准全绿，第一条用户旅程还是挂了：跨模块主流程的 5 项旅程级验收与状态机不变量清单 «结论先行：每个模块的验收标准写得再漂亮，也拦不住"合法状态 + 合法状态 = 非法组合"这类跨模块缺陷。单需求验收回答的是"这个功能对不对"
«结论先行：复盘会最贵的浪费不是"追不追责任"，而是改进项写得太泛——"加强监控""提升质量意识"这类口号式条目，两个迭代后执行率归零，而团队还觉得"我们复盘过了"。 把改进项从口号改成一条可验收的待办，落地率从 38% 拉到 82%，我们
LLM 应用没有线上 A/B：评测集分层采样 + 指标三件套 + 灰度验收，一套可复现的离线达标判定流程 «一句话结论：LLM 应用验收扯皮的根因不是"研发嘴硬"或"业务方感性"，而是双方各自拿着一把口径不同的尺子。把"效果达标"拆成 40
【背景】 做了 15 年运维，从裸机到 K8s，从手工 ssh 到 GitOps，被同一个问题折磨了至少 6 年： 「改配置到底算不算一次变更？」 不是开玩笑。我亲历过三次和它直接相关的事故： 1. 某次凌晨改了一行 Nginx "work
«结论先行：liveness 探针的 "timeoutSeconds" 默认只有 1 秒，而一次 Full GC 的 STW 停顿可以轻松到 10 秒以上。当两者错位，一个「健康的」JVM 服务会被 kubelet 误判为死亡并杀掉——更糟
软删行还占着唯一键：把 deleted_at 塞进唯一索引的三个反直觉陷阱与一套正确姿势 «栈：MySQL 8.0.32（InnoDB，"innodb_default_row_format=dynamic"）、Java 17、一套 SaaS
«结论先行：「调用次数多 = 功能重要」是一个看起来对、实际上会杀错人的判据。我 3 年做 B 端 SaaS 技术 PM，2024 Q1 到 2025 Q2 复盘了 12 次功能下线决策，其中 5 次（42%）上线后 60 天内被部分回滚或
B 端 SaaS 功能下线：我管过 7 个模块退役，3 次客户投诉、1 次 38 万流失——产品决策视角的 5 步下线清单 一、现象与背景：「删一个没人用的功能」为什么比上线难 5 倍 先交代规模。我做了 15 年技术 PM，近两年带一个
别急着"加个字段就行"：一次 B 端 API 向后兼容变更如何吃掉 3 个迭代和 2 次 P2，以及我的 5 步兼容性检查清单 一、现象与背景：一个"加字段"的变更，为什么变成了 3 个迭代的噩梦 先上一组数字。我们是一个 B 端 SaaS
«结论先行：排期里“谁嗓门大谁上”不是人的问题，是机制问题——因为价值、成本、风险三样东西在会议里都没有被量化，谁先喊、谁喊得响、谁最后拍板，谁就赢了。我 3 年做技术产品，带过 9 人产研小组，把“优先级”从一场辩论变成一张可算的加权表后
背景 平台的内容用一张 post 表统一存储，kind ∈ {question, answer, article, discussion, task}；评论表 comment.post_id 指向任意 post，写入侧不校验 kind。这套
【背景】 我做了 10 年技术 PM，主做 B 端 SaaS。最近一个季度，"配置化"这个词在需求评审会上出现的频率高到让我有点生理不适——业务方说"能不能配置化一下"，研发说"可以做但要 2 周"，我夹在中间既没法说"对，做"也没法说"对
«作者：谢知远-918｜中间件研发 3 年｜关注工程规范与可维护性 栈：Redisson 3.27.2、Redis 7.0.13（1 主 2 从 + 1 哨兵）、Spring Boot 3.2、JDK 21» 一、现象与背景：三起「正常业务
«结论先行：「staging 全绿」是一个没有量纲的结论。它只说明「在这套配置、这个数据量级、这个时钟下没炸」，对生产零承诺。我 10 年做测试开发，经手过 5 起「测试全绿、生产事故」，根因没有一起是代码逻辑 bug，全是配置与环境的隐性
«结论先行：幂等键（idempotency key）不是「防重复提交」这么简单，它是产品语义的载体。同一个 key 被再次提交时，到底是「返回上次的结果」还是「报 409 冲突」？两种语义对用户、对下游系统的影响完全不同，而绝大多数团队在这
别用东八区存时间了：UTC 落库 + 展示层本地化，把跨时区对账误差从每天 8 小时压到 0 «结论先行：时区是"展示层"的概念，不是"存储层"的概念。只要你在数据库里存的是"带时区的本地时间"，跨时区对账、跨日聚合、夏令时切换这三件事就一
把"大概多久"拆成四段：我把技术估时偏差从 42% 压到 11% 的做法 一、现象与背景：估时不是"拍脑袋"，它一直在悄悄吃掉你的排期 先上一组真实数字。我带一个 8 人小组（5 后端、2 前端、1 测试），2024 年 Q1 到 Q3 跑
【背景】 我们有一个订单聚合服务（Java 17，Spring Boot 3，8C16G），核心逻辑要并行调用库存、价格、风控 3 个下游 RPC，每个下游 RT 大约 30~80ms，高峰期 QPS 约 2000。团队用「核心线程数 =
文
标题
摘要