电商小程序的复杂度不只在页面数量。同一件商品的不同规格如何区分，重复点击如何影响数量，旧数据能否适配新表结构，都会影响用户眼里的“购物车是否正确”。DS 已包含后端、前端与数据库迁移实现，本文聚焦这些基础机制，不把代码存在等同于业务全部交付。
先看现有结构
后端采用 Python、FastAPI、Pydantic、PyMySQL 与 DBUtils，用 uv 管理依赖；前端为 Vue 3、Vuex 与 uni-app。仓库提供微信小程序、H5 和 App 构建脚本，但脚本存在不能证明每个端都已经构建并运行成功。
应用入口注册业务路由，api/ 承接接口，services/ 保存部分业务服务，core/ 提供数据库等公共能力。这不是所有请求都严格经过服务层的完整分层：购物车模块仍同时包含路由、模型与管理逻辑。描述真实结构，比给项目套上标准架构名称更有意义。
购物车里，SKU 才是规格身份
加入购物车之前，后端检查数量、商品与 SKU 的对应关系，再核对累计数量是否超过规格库存。查询时关联商品表和 SKU 表，取得展示信息与价格，而不是把名称或规格描述当作唯一身份。
行身份围绕用户、商品和 SKU 建立，写入结合事务内行锁与重复键更新处理数量累加。这样，不同规格可以独立记录，数量校验也有明确对象。不过，这里的库存检查只是购物车写入校验，不能等同于下单时的库存预占，更不能推出完整交易链路已经验证。
连接池解决的是资源借还
公共数据库层使用 DBUtils 连接池，按进程设置连接上限，首次初始化时加锁。连接通过上下文管理器借出，异常路径执行回滚，退出时归还连接；游标辅助方法提供提交逻辑。
这些处理减少了调用方重复组织连接生命周期的需要，也让异常时的资源释放有公共入口。但池的上限属于单进程预算，多进程部署仍要统筹总连接数。公共层有事务辅助能力，也不表示每个业务调用方的事务边界都已经正确验收。
前端统一请求封装集中处理超时、HTTP 状态与业务错误，区分登录失效、无权限和状态冲突，页面可以选择自行展示错误，减少重复提示。这让页面逻辑不必各自解释同一类失败。
迁移不是直接执行几条 SQL
购物车结构调整前，迁移脚本先检查历史数据中的歧义与重复；无法明确处理时停止，而不是猜测归属。脚本提供 dry-run 分支，迁移目录保存会话、头像审核和会员权益相关的表结构变更。
这些文件把数据结构演进变成可追踪的交付内容，却不能证明目标数据库已经执行了它们。测试所用迁移、提交包含的迁移与实际执行的迁移，应当是同一份明确清单，不能只凭工作区运行成功判断发布完整。
后续验证的重点
下一步应在隔离数据库中验证旧数据升级路径，并把迁移版本、执行记录与发布清单关联。接口侧则继续统一字段和错误契约，用业务链路测试同时检查页面、接口与数据库状态。
本文未运行测试、构建或迁移，因此不报告连接池性能收益、并发承载能力或多端可用性。工程机制值得记录，运行结论需要另外取得证据。
实现线索
连接管理见 core/database.py，购物车见 api/order/cart.py，迁移检查见 scripts/migrate.py。文中不涉及真实用户、交易数据或内部服务信息。