V3.03.3Lock timeout and forced release设计
锁需要超时与强制释放
别名: 锁超时 · 强制解锁 · 抢占式释放
概念解释
任何锁定机制都必须配两样兜底：超时释放（持锁超过设定时间且无活动，锁自动解开）与强制释放（具备权限的人可以把锁从持有者手里拿走）。没有这两样，一把遗忘的锁就能无限期占用一块共享空间，锁的保护功能反转为单点故障。这两个机制的共同作用是把锁从「持有者的财产」改回「团队的租借物」——可以有排他性，但不可以有无限排他性。
机制
超时与强制释放解决的其实是同一个问题的两个时间尺度。超时处理无人响应的情形：持锁人已离开，等他确认释放等于永远等，所以规则必须能在他缺席时自动执行——判定输入是活动信号（还在编辑）而不是墙钟时长（拿得久），否则长时打磨的人会被误伤。强制释放处理有人响应但不配合或情况紧急的情形：持锁人在但拒绝放、联系不上、或者他锁住的区域正阻塞一件更紧急的事。此时需要一个越级的出口，但这个出口本身必须被约束——谁来按、按了之后发生什么、被释放方的未保存修改怎么办，都要有明确答案，否则强制释放会沦为「谁急谁有理」的通道。释放后的交接同样关键：原持有者若还有未落盘的修改，应以待合并版本的形式保留，而不是随锁一起蒸发。
边界
超时阈值没有普适数值：编辑一段代码与打磨一段文案的合理持有时长差一个量级，阈值应随对象类型与历史持有时长分布调整，而非全局一刀切。强制释放的权限设计也有反面：若人人可随时抢锁，锁的排他承诺就名存实亡，人们会退回「先把内容扒到本地再说」的自保行为。合理的落点通常是受限的强制释放——需要更高权限或给出理由，并通知原持有者。对极短的锁（秒级）超时反而是噪声，这种锁应直接用无锁算法或自动合并替代。
怎么落地
- 每种锁定义「无活动」的判定信号（输入、心跳、页面可见性），超时基于活动信号而非纯时长。
- 超时触发先温和提示（持锁人还在就续期），无响应再自动释放并通知双方。
- 强制释放入口对受限角色开放，必须填理由、自动通知原持有者、在审计日志留痕。
- 释放时若持锁人有未保存修改，转入待合并版本而非丢弃。
- 验证：注入测试——模拟持锁人掉线不释放，量测从掉线到锁可被他人使用的时长；超过目标（如 15 分钟）即不合格。再模拟一次强制释放，检查通知、留痕与未保存修改的保全是否都发生。