一、选型：从 Capacitor 转向 uni-app x
最初想用 Capacitor 把 Web 包一层出原生，很快发现它在我们这场景走不通——尤其鸿蒙侧的驱动和真机链路不顺畅。最终选定 uni-app x（HBuilderX 5.26），一套代码编译出安卓 App、鸿蒙 .hap 和 H5。前期只验证安卓 + 鸿蒙两端，小程序备案另行处理。
一个易漏点：工程必须被识别成 uni-app x——要在 manifest.json 补 uni-app-x 节点。缺它，工具链会把项目当成 JS 版 uni-app，编译通道全错。
二、坑：安卓编译最严，H5 绿 ≠ 安卓绿
三方通道里，安卓是类型检查最严的编译器，唯一能暴露 any 类问题的地方。H5 通道不会编译安卓/鸿蒙特有的条件分支（条件编译会把它们排除），所以 H5 跑通只证明语法层面，最终以安卓真机为准。
- 首轮编译暴露 4 类 UTS 强类型错误，修正后钉死类型名/API 名/参数名；
- 安卓真机六项（环境、登录、拉列表、扫码、录音→ASR、主题）全绿才算过；
- 鸿蒙先用 DevEco 模拟器冒烟，真机安装差一张调试证书——这是第 2 期开工前必须补齐的。
三、外壳架构：一个页面，多面板用 v-show 切
底部 tab 我们没有用内置 tabBar，而是自绘。整壳是一个页面 + 多个面板，用 v-show 切换（禁 v-if、禁换页），避免切换时整页重建丢状态。tab 定义收敛到唯一真源 common/ui/shell.uts，两套外壳（管理 / 车间）共用。
- 图标零图片：tab 图标是纯 CSS 画的（几个空 view + 类名），整套 App 不依赖任何图片资源，安装包更轻、也不怕图裂。
- 不是把网页搬过去：老板明确要求「不要把网页版搬到手机上」——AI 助手面板按手机竖排重排卡片，不搬电脑端的横向宽表。
四、网络层两条铁律
移动端网络比桌面不可靠，两层设计直接决定稳定性：
- 网络状态双源：「可达」= 系统链路事件 且 后端没被证否。只用系统事件会误判（连上 Wi-Fi 但后端挂了），只用请求结果会漏报。两者取交集才显示「在线」。
- 401 单飞铁律：并发多个请求同时 401 时，只刷一次令牌，其余请求等刷新后重放一次；网络失败（0）/5xx 绝不清空会话——清会话会让用户莫名退出登录。
五、复盘
- 选能驱动双端的工具链：Capacitor 走不通就尽早换，uni-app x 在安卓/鸿蒙双端真机验证上更可控。
- 以最严编译器为准：安卓是类型终检，H5 通过只是起点。
- 外壳做成一个页面多面板：状态不丢、tab 定义单一真源、图标零资源。
- 网络层两条铁律写死：双源判可达、401 单飞、失败不清会话。