不追新，
但每条业务线都要站得住。

不同业务线解决不同问题，技术构成也不同。下表按业务线列出主力技术、 当前成熟度与主要约束，避免用一套话术覆盖所有场景。

平台采用模块化单体（modular monolith）结构：单个可部署单元，内部按领域切分模块， 模块之间通过明确的接口通信。这个选择是刻意的—— 在区域产业带的业务体量下，微服务带来的分布式事务与运维复杂度， 远大于它带来的弹性收益。

代价是横向扩展粒度较粗，收益是追溯链路里的跨模块操作可以在本地事务内完成， 不必为「赋码与质检记录必须同时成功」去设计补偿逻辑。

React 和 Vue 我们都在用。这不是「什么都试一下」，而是按端的特性分工： 后台管理要复杂表格与表单，移动端要包体小、启动快，小程序要一套代码多端运行。 用错框架不会让项目失败，但会让每一次改需求都变贵。

选型分工

六个前端工程的实际组合

下面这张表来自各工程的依赖清单，版本可核对。写这一行不是为了罗列， 而是说明「同一个团队能同时维护两套技术栈而不失控」——靠的是统一构建与统一规范。

后端框架

工程化的几条硬规矩

• 全项目 TypeScript：六个前端工程统一 TS 5.4，接口返回类型必须有定义，不用 any 兜底。
• 构建工具统一：除小程序外统一 Vite 5，构建配置集中维护，避免每个工程一套写法。
• 路由懒加载：按路由分包，首屏只加载当前页面依赖。
• 请求层统一封装：axios 拦截器统一处理令牌刷新、错误码与静默请求，不在页面里散写。
• 不滥用状态库：Vue 侧两个工程没有引入 Pinia——页面级状态加本地存储足够，多一个依赖就多一处维护成本。

多租户系统最常见的漏洞不是加密没做好，而是某条查询忘了加 tenant_id， 于是 A 企业的数据被 B 企业看到。这类问题无法靠代码评审完全避免， 必须在架构层面兜底。

• 行级隔离：所有业务表带 tenant_id，租户之间共用表结构但数据严格分离。
• 上下文传递：令牌中携带租户标识，请求进入应用后写入租户上下文，业务代码从中取值。
• 强制兜底：数据访问层对业务表自动追加租户条件，即使业务代码漏写也不会越界。
• 写入校验：新增与更新时校验租户归属，拒绝把数据写到其他租户名下。
• 码段隔离：Ecode 码段按租户分配，跨租户使用同一个码会被直接拦截。

-- 业务查询实际执行的形态（示意）
SELECT id, code_value, batch_no, status
FROM trace_code
WHERE code_value = ?
  AND tenant_id = ?        -- 由上下文注入，业务代码无须重复书写
  AND deleted = 0;

数据库里的记录，管理员理论上可以修改。追溯系统如果无法证明「这条记录没被动过」， 它的证明力就有限。平台的应对方式是把关键节点串成哈希链： 每条记录包含前一条记录的摘要，任何一条被改动，后续链条全部对不上。

// 存证节点的构造方式（示意）
node_hash = SHA256( prev_hash + tenant_id + biz_type + biz_id + payload + created_at )

// 校验时从任意节点回溯，逐条重算并比对
verify(n) = node_hash(n) == SHA256( prev_hash(n) + ... )  && verify(n-1)

• 覆盖节点：备案、赋码、质检、出库、查验等关键业务事件写入存证链。
• 可校验：任一节点可独立重算摘要，与链上记录比对，判断是否被篡改。
• 定位断点：校验失败时能定位到具体哪一条记录异常，而不是整体判废。
• 与业务解耦：存证不阻塞业务主流程，写入失败进入补偿队列，不影响正常作业。

车间与仓库的 Wi-Fi 覆盖常常不理想，如果扫码端强依赖实时联网， 产线一断网就停摆。平台在设备侧做了相应处理。

• 弱网可用：PDA 端支持扫码记录的本地暂存与恢复联网后的补传，避免作业中断。
• 幂等提交：重复提交同一批扫码记录不会造成重复扣减，网络抖动不会污染库存。
• 设备适配：支持常见手持终端的扫码广播，也支持手机摄像头扫码，不必采购专用硬件。
• 标签打印：打印代理对接本地标签机，码图由服务端生成，避免前端渲染差异导致码不可读。
• OCR 辅助：面单与纸质单据可通过 OCR 服务识别，减少手工录入错误。

服务端采用多阶段构建：构建阶段完成编译与打包，运行阶段只保留 JRE 与产物。 运行时镜像基于 distroless，不含 shell、包管理器与常见调试工具， 以非 root 用户运行，显著缩小容器被突破后的可利用面。