本地优先不是原教旨主义：哪些数据适合不出门，哪些别硬扛

聊了两次本地优先（架构门槛、本地推理），今天泼一盆冷水：本地优先不是教条。把它当信仰的团队，最后往往在错误的场景硬扛，付出了十倍成本。今天划一下边界——什么该本地，什么该上云。

天该本地的三类

1. 用户隐私数据：笔记、日记、健康记录、聊天历史。这类数据的所有者是用户本人，任何「上传到厂商服务器」的默认行为都是在消耗信任。本地优先在这里不是技术选择，是产品伦理。

2. 高频小数据：每天调用成百上千次的配置、词典、索引缓存——网络往返的延迟和流量成本，跑在本地几乎是白嫖。典型如翻译工具的术语库：几 MB 的数据，放云端每次查询多 200ms，放本地零成本。

3. 合规红线数据：医疗、法律、金融的行业文档。这不是「 preference」是「regulation」，没得选。

不该硬扛的两类

1. 大模型推理（多数场景）：端侧模型最近进步飞快，但「能跑」和「好用」之间隔着算力鸿沟。用户设备上跑 7B 量化是极限，企业级任务的_quality_要求往往得云端大模型。混合方案才是现实解：简单任务端侧、复杂任务云端，路由规则透明。

2. 需要协作的数据：本地优先最难的敌人是多端同步。单机的完美体验，一到「第二台设备」就变成冲突处理的泥潭。CRDT 之类的同步技术成熟度还不够托付给普通团队——如果协作是核心场景，云优先更诚实。

我的边界判断法

一个简单的测试：这份数据泄漏了，用户会找谁？ 找你（产品方）——本地优先；找运营商/云厂商——那是基础设施的问题，不用你操心。再算一笔账：本地化的开发维护成本 ÷ 隐私价值，比值超过一个阈值（我们内部定的是 3 倍），就上云。

结语

本地优先是工具不是主义。真正值得坚持的是「数据默认属于用户」这个原则，至于实现路径——本地、云端、混合，按场景选最顺手的。边界划清楚，才能把有限的本地位留给真正值得的数据。