本次草稿依据提交记录，未逐行核对实现。依据：（2026-10-29，SDK 58 upgrade, home journal, refinement workbench, camera, migrations 031-037）、（2026-09-30，统一客户端迁移至 Expo / React Native Web）。 的架构：Expo SDK 57、React Native 0.86、React Native Web 0.21，123ABC；Vite 内部后台在 456DEF；Dockerfile 多阶段构建。README 实证：用户端已统一到 123ABC，同一套路由/业务页面/数据层输出 Web、iOS、Android。本文不编造 SDK 58 的具体变更日志。
统一客户端是什么
之后，结构一句话能说清：用户端统一到 123ABC，同一套路由、业务页面、数据层输出三端；内部后台在 456DEF，用 Vite；两者用共享运行时契约衔接；部署用 Dockerfile 多阶段构建。关键不是“少了一套代码”，而是“少了一套分叉”：路由、业务页面、数据层最容易分叉，Web 一套路由、iOS 一套导航、数据层各写一份，时间一长，三端行为会悄悄长得不一样。统一是把这三层收敛到同一实现，差异只留在真正需要区分的地方，如原生才有的相机、推送、本地存储。
代价也很直接：统一后任何改动都要考虑另外两端。改一个页面，要同时想它在手机与浏览器里的样子；改一个接口，要同时想它在 IndexedDB 与 SQLite 上的表现。统一是把“三套代码各自为政”的成本，换成“一套代码处处留心”的成本。
SDK 58 升级：账单由四部分组成
把几件事并列在一起：SDK 58 upgrade、home journal、refinement workbench、camera、migrations 031-037。这说明升级不是孤立的依赖更新，而是与首页日记、精修工作台、相机、数据库迁移一起交付的，验收不只是“能不能跑起来”，还包括这些功能在新 SDK 下是否正常。
账单第一部分是 SDK 与原生依赖：每次大版本都会带动一批原生依赖变化，先对齐依赖，再看编译过不过；最怕“编译过了，行为变了”，行为变化只能靠回归测试抓。第二部分是相机等原生模块：提交信息单独点了 camera，说明它是重点验证对象，权限、预览、拍摄、存储、机型兼容都可能变化，且必须上真机验证。第三部分是数据库配套：迁移 031-037。七个连续迁移与升级同批交付，部署顺序就有讲究：先跑迁移再起新版本，还是反过来？旧客户端遇新结构怎么办？迁移失败能否回滚、定位到是哪一个？具体改了什么，本文不编造。第四部分是回归点：首页日记是第一眼看到的东西，精修工作台是内容生产核心流程，两者是重点回归对象。
升级 Checklist
依赖对齐：核对 SDK 58 要求的基础版本，逐个升级原生依赖。编译验收：三端分别编译通过，警告也要过一遍。原生模块回归：相机、推送、本地存储等逐个在真机验证行为一致。数据库迁移：031-037 按顺序执行，验证每步状态，准备失败定位与回滚方案。核心路径回归：首页日记、精修工作台全量走一遍。三端一致性检查：逐项对照，修“意外的差异”，留档“预期内的差异”。发布与回滚：确认顺序、灰度策略与回滚时迁移怎么办。SDK 58 变更日志以官方升级指南为准。
收益与代价
收益是改一处、三端生效：修一个数据层 bug，三个端一起好；加一个业务功能，三个端一起有。对小团队，这是最实在的收益。其次是行为一致：同一套路由与业务逻辑，三端用户走同一条路径、看到同一套状态流转；在 Web 写的日记，在 iOS 打开应是同一状态。第三是契约先行，联调扯皮少很多。
代价第一是原生构建仍需真机验收：统一的是业务代码，不是原生构建，iOS 仍走 Xcode，Android 仍走 Gradle，原生模块仍要在真机验证；升级最花时间的部分往往不在 TypeScript 层，而在原生构建层。第二是差异要显式管理：三端不可能完全一样，差异应收敛到明确的分支点并写清原因；分支散落各处，统一就名存实亡。第三是升级影响面变大：以前 Web 升级只影响 Web，现在 SDK 升级影响三端，回归范围、发布风险、回滚成本都变大了。这也是把升级、功能、迁移放同一次提交的原因：影响面大了，交付就要更整。
小结
SDK 58 升级不是单纯的依赖更新，而是一次在统一客户端架构下的跨端迁移。账单由依赖对齐、原生模块回归、迁移 031-037、核心路径回归四部分组成；收益是改一处三端生效、行为一致、契约先行；代价是原生构建仍需真机验收、差异要显式管理、影响面变大。账算清楚了，升级就不再是“升个 SDK 试试”，而是一次有清单、有回归范围、有回滚预案的迁移。
