从需求到上线：一个药事服务 B2B 平台的全栈交付实录

最近完成了一个医药行业 B2B 管理平台的交付，客户是一家从事中药材流通的企业，平台连接药企、诊所与药房三方。应客户保密要求，品牌信息做了脱敏，但技术方案和踩过的坑可以完整分享——如果你也有类似的行业系统定制需求，希望这篇文章能让你看到我们做事的方式。

一、业务背景：一个三方协同的 B2B 场景

先说业务。医药流通行业的数字化有一个典型痛点：上游药企、中间诊所、终端药房，三方的库存、订单、价格体系互不打通。客户原来的作业方式大量依赖微信群里接单、Excel 对账，出错率高、对账周期长。

这个平台的定位就是一个三方协同中枢：

• 药企端：药品目录管理、库存管理、订单履约、价格策略；

• 诊所/药房端：在线下单、采购单跟踪、收货对账；

• 平台侧：会员管理、订单中台、数据看板。

典型链路是：药房在线下单 → 平台拆单路由 → 药企确认库存并发货 → 双方在线对账。听起来不复杂，但医药行业叠加了批号效期、GSP 相关的数据留痕要求，加上 B2B 场景特有的阶梯价、账期结算，复杂度集中在数据模型和状态机上。

二、技术架构：前后端分离，但分离得有章法

技术选型上没有追新，核心原则是团队熟悉度 + 长期可维护性：

层次	选型	理由
后端框架	Spring Boot + MyBatis-Plus	生态成熟，团队可控
参数校验	Jakarta Validation	校验规则内聚在 DTO 层，接口自文档化
前端框架	Vue 3 + TypeScript	组件化开发效率高，类型安全
部署	Ubuntu + Nginx	运维成本最低，后续可平滑迁移到国产化环境

几个我认为值得展开的设计决策：

1. 统一响应体系，从第一天就定死

很多项目死于"每个接口一个返回格式"。这个项目从一开始就强制了 ApiResponse / PageResult 两个统一封装，业务码、消息、数据、分页元信息全部收敛。后端省掉了大量重复胶水代码，前端的请求封装也能做统一的错误拦截和登录态失效处理。

2. 序列化精度问题：Long 转 String

B2B 场景订单量大，主键用的 int8（Long）。前端 JS 的 Number 只有 53 位安全整数，Long 直接序列化会静默丢失精度——这种 bug 上线了才暴露，排查成本极高。我们在序列化层统一处理了 Long → String 的转换，前端拿到的 ID 永远是字符串。一个看似很小的点，是很多团队踩过坑才知道的。

3. 数据层规范

逻辑删除全局启用、审计字段（创建人/时间、更新人/时间）强制携带、命名规范统一。这些在项目早期看不出价值，但到二期三期迭代时，数据可追溯性就是救命稻草——尤其医药行业对数据留痕有硬要求。

三、质量治理：我们用"审查驱动"代替"bug 驱动"

这是我比较想强调的部分。项目主体功能完成后，我们没有直接进入维护模式，而是做了两轮系统性的代码审查，按 Checklist 逐文件过，把发现的问题收敛成编号 Issue，逐项闭环。

后端治理（Phase 3） 包括：

• 校验体系补全：所有写接口强制 @Valid，把非法数据挡在业务层之外；

• 逻辑删除一致性：修复了若干绕过逻辑删除标记的查询；

• 接口文档安全：Swagger 生产环境关闭暴露，避免接口信息泄露；

• 序列化策略统一。

前端治理（Phase 4） 聚焦六个维度：组件体积（单组件超 400 行必须拆分）、代码重复度、Vue 最佳实践、样式规范、性能优化、安全漏洞。典型动作包括：

• 全量消灭 any 类型，TypeScript 严格模式落地；

• 统一 API 层封装，上传、下载等公共逻辑收敛到独立模块；

• 拆分巨型组件，可复用逻辑抽成 Composables。

效果是实打实的：审查后新增需求的返工率明显下降，新人接手成本也低了——因为代码风格和分层是可预期的。

四、一个架构权衡的真实案例：DTO 还是 Map

分享一个我和合伙人讨论了很久的选型：对外接口的数据传输用 DTO 还是 Map。

教科书答案当然是 DTO：类型安全、字段明确、Swagger 文档友好。但我们在实践中发现一个问题——Jackson 默认会静默丢弃未知字段。上游系统加字段、我们没同步更新 DTO，数据就无声无息地丢了，不会报错、不会告警，等业务发现时已经丢了一串数据。

对于字段频繁变动、由多方共同演进的数据结构，我们最终选择了更务实的方案：强类型核心链路用 DTO，动态演进的数据块用 Map 承接，并在接入层做显式的字段校验。这不是最优雅的方案，但它把"静默数据丢失"这个最危险的故障模式显式化了。

我的观点是：架构决策没有标准答案，关键是清楚每个选择背后规避了什么风险，并且团队共识一致。

五、部署与国产化视角

项目部署在 Ubuntu + Nginx 环境，域名解析、HTTPS 证书、反向代理、静态资源缓存策略都是标准动作，不再展开。

值得一提的视角是信创合规。医药行业客户对国产化替代的诉求越来越明确，我们在选型阶段就刻意规避了深度绑定特定商业中间件的方案——数据库、操作系统层面都预留了向国产环境迁移的路径。信创不是一句口号，是从第一行代码就要考虑的事。

六、写在最后

这个项目从需求梳理到上线，我们跑完了完整闭环：业务建模 → 架构设计 → 前后端开发 → 两轮质量治理 → 部署上线。团队规模不大，但方法论是完整的：

• 前后端全栈覆盖，字段命名、接口契约一侧对齐，减少联调内耗；

• 审查驱动的质量体系，问题以 Issue 编号化管理、逐项闭环；

• 架构决策有据可查，权衡过程透明。

如果你所在的行业也有类似的系统定制需求——无论是 B2B 协同平台、管理后台还是行业信息化系统——欢迎交流。我们在医疗、医药流通领域积累的不仅是代码，还有对这类业务的数据模型和合规要求的理解。