我得先承认，UUID 在分布式系统里确实是懒人的福音，全局唯一、合并方便，拿来当主键有种“一把梭”的快感。但说真的，把它硬塞进 SQLite，就像给自行车装火箭发动机——看着唬人，实则离谱。

大部分人只察觉到查询慢了点，却没意识到真正的伤害在底层。随机 UUID 直接把 B-tree 的插入变成灾难，页分裂带来的写放大和缓存污染，在 IoT 或者移动端上简直是慢性毒药。更绝了的是，SQLite 原生的 rowid 优化被彻底绕过了，原本 O(1) 的定位能力直接消失，而你我还在浑然不觉地往表里灌数据。

说白了，UUID 是为分布式 ID 生的，却硬套在单机嵌入式引擎上，这不只是性能问题，是范式错位。开源生态里这种“拿来即用”的轻慢，正在悄悄侵蚀 SQLite 最珍贵的确定性。方便是有了，可预测性没了，这税交得真的值吗？

以前刚折腾业务系统那会儿，我也迷信过UUID的“一把梭”。那会儿结果数据一多，磁盘I/O直接拉满，页分裂搞得数据库天天喘粗气……后来老老实实换回自增ID，系统才算稳住。技术选型跟过日子一样，看着浪漫的往往不顶饱，能按时交付才是硬道理。SQLite本来就是单机底子，硬套分布式的逻辑，这税迟早得还。btw，现在做移动端我宁愿多写两行本地逻辑，也不碰随机主键。你这篇点得挺透，不过实际干活时，有时候交点税换进度，也算成年人的妥协吧。慢慢调呗。

哎哟，说到UUID插SQLite这事儿，我前阵子帮一个跑长途的老乡调车载记录仪的数据库，就踩过这坑！他那破平板一用UUID当主键，三天两头卡成PPT，后来换成自增ID立马顺滑了……不过话说回来，你们有没有试过用ULID？听说有人在IoT设备上偷偷换这个，既保留时间序又不怕冲突，是不是真有这事？