写代码不是"能跑就行"，而是"每次都能跑对"。以下是团队里血淋淋的Bug换来的实战经验：
1. 命名即注释，拒绝心理暗示
不要用 flag、tmp、data 这种"反正我知道什么意思"的命名。布尔值必须用 isValid、hasPermission、shouldRetry 等前缀。曾有同事用 status 表示"是否已删除"，结果另一位理解成"是否已激活"，导致数据被物理删除。
2. 所有外部输入都是不可信的
不要假设用户会传什么、数据库返回什么、API会返回什么。每个函数入口做防御性校验：
# 坑：直接调用
user_name = data['name'].strip()
# 避坑：层层设防
user_name = (data or {}).get('name', '').strip() if isinstance(data, dict) else ''3. 警惕"幽灵常量"
代码里出现的 3、1000、86400 就是定时炸弹。 extract 成常量并写明业务含义：
// 错误
if (retryCount > 3) ...
// 正确
private static final int MAX_RETRY_COUNT = 3; // 超过则转人工审核4. 边界条件要"左闭右开"且显式
处理数组、分页、时间范围时，永远写明是否包含边界。推荐左闭右开 [start, end) 模式，并单独写单测验证 0、-1、null、最大长度等极端情况。
5. 对象引用是隐形地雷
Java/Python 中的对象赋值是引用传递。修改"副本"却改掉原数据是高频Bug：
# 坑：config 和 default_config 指向同一对象
config = default_config
config['timeout'] = 30 # 把默认配置也改了！
# 避坑：深拷贝
config = copy.deepcopy(default_config)6. 异步代码显式标记状态
并发或异步操作必须明确状态机（pending/success/failed），避免"重复提交"或"回调地狱"中状态混乱。不要用 if (result != null) 来判断异步完成，用明确的 status 字段。
7. 异常捕获要具体，不要裸 try-catch
永远不要 catch (Exception e) 然后吞掉。区分"可恢复异常"（网络超时重试）和"程序错误"（空指针直接抛）。至少打印堆栈，别只写 log.error("出错了")。
8. 时间处理避开语义陷阱
不要用 Date 做计算，用时间库（Java的LocalDateTime、Python的Arrow）。特别注意：
- 时区转换显式化（别依赖服务器默认时区）
- 不要用
==比较浮点数金额（用分存储，或BigDecimal）
9. 删除代码比添加代码更需要评审
修改Bug时，检查是否还有其他雷同代码段（Ctrl+C/V 的代码往往有同样Bug）。重构时先跑通全量测试，再删旧代码，别相信"我印象中没人调用这个方法"。
10. 复杂逻辑必须单元测试护航
if 嵌套超过3层、正则表达式、状态机流转，这些"看起来没问题"的代码，必须用单元测试覆盖分支覆盖率（Branch Coverage）>80%。花10分钟写测试，省得半夜2点回公司修数据。
一句话总结：代码首先是写给人看的，顺便给机器运行。当你写下一行代码时，想象半年后的你在凌晨三点接到报警电话，试图理解这段代码——对自己仁慈一点。