线程同步死锁防御：设计良好的资源分配原则

资源有序分配是防御死锁最直接有效的方式：为每类资源赋予全局唯一、稳定不变的编号，申请必须严格升序，释放可任意顺序但禁止边用边放，跨模块调用需上层统一分配排序。

线程同步死锁不是偶然发生的，而是资源分配逻辑出错的必然结果。防御死锁的关键不在于加锁更“快”，而在于让所有线程对资源的获取行为可预测、无歧义——资源有序分配正是实现这一点最直接有效的方式。

给每类资源一个固定编号

编号必须全局唯一、稳定且不可变更。比如数据库连接池设为101，文件句柄设为202，网络端口设为303。编号不依赖创建顺序或运行时状态，也不随部署环境变化。编号越小，优先级越低；编号越大，层级越高。这样所有模块在设计阶段就能明确自己操作的是哪一级资源，避免临时拍脑袋定序。

申请资源必须严格升序

一个线程若需同时使用编号101和303的资源，必须先申请101，再申请303；若已持有303，就绝不能回头申请101或202。这不是建议，是硬性约束——可在工具层封装校验逻辑，例如在资源管理器中传入资源列表后自动排序并拦截逆序请求。

• 调用方传入资源A（ID=303）、B（ID=101），底层自动重排为B→A执行
• 运行时检测到某goroutine已持ID=202锁，又尝试Lock(ID=101)，立即panic或返回错误
• 静态检查工具可在编译期扫描加锁语句，标记潜在逆序调用

释放资源不强制顺序，但要避免“边用边放”

释放可以按任意顺序进行，这是为了降低实现复杂度。但要注意：不能在持有低编号资源期间，释放高编号资源后又重新申请更低编号的资源。例如，持有了101和303，先释放303没问题；但如果接着又去申请202，就可能打开死锁缺口——因为另一线程可能正持202等101。

• 推荐统一在临界区末尾批量释放，或用defer按申请逆序释放（即先申请的最后释放）
• 禁止在临界区内嵌套新资源申请，除非能确保新资源编号高于当前持有全部资源
• 对跨模块调用，把资源需求声明为输入参数，由上层统一分配和排序

编号策略要兼顾扩展性与一致性

静态编号适合核心资源（如DB、Cache、MessageQueue），动态编号可用于插件式资源（如用户自定义处理器）。但两类编号域必须隔离，例如核心资源用1–999，插件资源从1000起跳，并预留间隙。编号本身不体现性能或权重，只表达获取先后关系。

• 避免用业务含义编码（如“订单服务=100，支付服务=101”），防止后续新增服务导致插入困难
• 编号可映射为枚举常量，在代码中直接引用，杜绝魔法数字
• 文档中公开编号表，并纳入CI流程校验，防止不同团队定义冲突