⚠️ 只会用聊天型大模型、最近开始想跟进 AI 新工具的普通人，最容易在这种消息上吃亏：看到 sqlite-utils（管理 SQLite 本地数据库的小工具）4.1.1[C001]，觉得只是补丁小修，就顺手划走。真错不在少看一条更新，而在你把下一步判断做反了：如果只盯表面热闹，你很容易在错误方向上花掉时间、预算和注意力，严重时还可能把关联数据一起赔进去。[C002]
具体场景很像这样：你刚刷到这条消息，本来想略过，但又怕自己落后。你以为“补丁版不用管”，或者“改表时外面再包一层事务就更稳”。问题偏偏出在这里。更隐性的代价，是你会一直围着表面热闹转，却看不到 sqlite-utils 4.1.1 真正改掉的那一步。
这次最值钱的，不是多了什么功能，而是 4.1.1 先拦住了静默级联删除：4.1.1是在防你改表时误删关联数据。[C002] 一条更新值不值得看，不看它列了多少功能，先看它会不会改掉你下一步的判断。
官方给的关键信息很直接：在“有外键关联、又包了事务”的特定场景里，改表动作 table.transform() 会直接抛出 TransactionError（可以理解成：先把危险操作拦停），避免旧表被删掉那一下，悄悄影响后面引用它的行。[C003] 这不是在教你怎么更方便改表，而是在阻止一种“看起来更安全”的写法把数据带坏。
另一条说明把原因讲透了：这个改表过程需要临时关闭外键检查，但外键检查那个开关在事务里又切不了，所以工具干脆拒绝执行。[C004] 这里边界也要说清：不是“4.1.1 普遍会删库”，而是触发条件很具体；也正因为具体，这次更新才更容易被误判成“小修补”。
所以我的动作很简单：你只要会改表结构，表和表之间还有关联，就把 4.1.1 放进“值得跟”的名单；你要只是拿本地小表记账、几乎不改结构，优先级没那么高，但这个坑最好先知道。[C001] 身边谁还默认“包个事务一定更安全”，把这条转给谁。
🤔 你现在最想先避开的，是哪一个坑？