这周我的核心工作是把“家庭药物管理模块”里最关键的一条链路真正跑通从用户扫码 → 到数据入库 → 再到可展示的完整闭环相比之前偏设计和讨论的阶段这一周更像是在“把想法变成真正能跑的系统”。一、这周真正解决了什么问题表面上看是做了一个“扫码入库功能”但实际拆开后会发现这里面有一个关键认知问题条形码 ≠ 药品信息扫码得到的只是类似6907992100090这样的一串数字它本身不包含任何“布洛芬”或“感冒药”的语义。所以整个流程其实分成两层前端负责识别“码”后端负责理解“码”代表什么这也是我这周在架构上做的第一个重要拆分。二、一个关键设计不要让 drug_info 卡死主流程一开始最容易想到的方案是扫码 → 查 drug_info → 有就入库没有就失败但这个设计有个致命问题药品库不完整时整个系统会“不可用”所以我做了一个比较关键的调整允许“药品库不存在”也能入库也就是user_drug用户药箱优先保证可用drug_info药品库用于“增强能力”而不是“前置依赖”这个设计带来的变化是用户体验不会被数据库拖累后续可以通过 OCR、人工补录慢慢完善药品库三、后端里的一段设计这周我专门抽了一层第三方条码识别网关public class ThirdPartyBarcodeGateway { public DrugInfo lookup(String barcode) { // 当前是 mock后续可替换为真实 HTTP API if (barcode.equals(6907992100090)) { return new DrugInfo(布洛芬, 解热镇痛); } return null; } }这个东西的意义其实不在“功能”而在“边界”把“外部依赖”从核心业务里隔离出去这样以后如果接入真实第三方 API或更换数据源只需要改这一层不用动 Service 和 Controller这属于典型的“为未来变化留接口”。四、自动计算过期时间放后端我这周还做了一个看起来很简单但其实挺关键的决策过期时间统一由后端计算LocalDate expiryDate manufactureDate.plusMonths(24); long daysLeft ChronoUnit.DAYS.between(LocalDate.now(), expiryDate);原因有两个避免前后端逻辑不一致保证数据存储是“结果”而不是“原始输入”也就是说数据库里存的是expiryDatedaysLeftstatus而不是让前端每次去算。这一步其实是在往“数据可信性”靠。五、前端这周的一个真实坑这周前端踩的一个比较烦的问题是kotlinx.serialization推断失败本质问题不是代码错而是构建环境 插件 泛型推断 三者冲突最后我给自己定了一个更务实的策略不死磕框架能稳定跑优先所以我倾向于改成val json JSONObject().apply { put(barcode, barcode) }这件事让我有个挺明显的感受工程开发 ≠ 技术最优解而是“可控 稳定”六、这周最大的收获开始在做架构选择如果只看功能这周其实就是扫码入库展示但对我来说更重要的是1. 开始主动做解耦条码识别 ≠ 药品数据user_drug ≠ drug_info2. 开始考虑系统不会卡死药品库缺失 → 不影响入库后续再补3. 开始为未来功能留接口OCR禁忌分析第三方 API七、当前还存在的问题目前1. 前端序列化还不稳定准备直接换实现方案2. drug_info 缺失时前端交互不够好需要引导用户“补录说明书”3. OCR 还没真正接入下一阶段重点八、这一阶段的总结如果用一句话总结这周我把“一个功能点”做成了“一条完整可运行的数据链路”系统现在已经具备能扫码能入库能计算能展示更重要的是架构已经允许它继续长大而不是推倒重来这对我来说是这周最大的进步。