beego框架不提供旅游业务逻辑，核心难点在于订单状态机、库存一致性、支付幂等及多供应商聚合；需手动事务控制、唯一索引防重、supplier_id拆分扩展、date类型存出发日、验签+redis幂等处理回调。
Beego 框架本身不提供旅游业务逻辑，直接用它“实现预订系统”会陷入重复造轮子——核心难点从来不是框架选型，而是订单状态机、库存扣减一致性、支付回调幂等、多供应商线路聚合这些领域问题。
为什么别急着写 controllers/OrderController
新手常从「用户点击下单」开始编码，结果卡在库存超卖或支付成功但订单没更新。Beego 的 Insert() 和 Update() 默认不带事务控制，MySQL 驱动也默认关闭自动提交。你得手动用 orm.RunTransaction() 包裹整个下单流程，否则并发请求下 SELECT stock 和 UPDATE line SET stock = stock - 1 之间存在竞态窗口。
- 务必在事务内完成「查库存→扣库存→生成订单→记录日志」四步，缺一不可
- 库存字段建议用
INT UNSIGNED并加CHECK (stock >= 0)，避免负数写入 - 不要用 Beego 的
orm.ReadOrCreate()处理订单唯一性校验，它不防重放；改用数据库唯一索引 +INSERT ... ON DUPLICATE KEY UPDATE
models/Line 设计要预留供应商扩展字段
旅游线路往往来自不同供应商（如携程API、自有地接社、第三方B2B平台），硬编码成单表会导致后期无法区分结算规则和数据同步方式。别把所有字段塞进一个 Line 结构体。
- 拆出
supplier_id字段，关联suppliers表，存储api_base_url、auth_type、commission_rate等元信息 - 线路价格字段用
price_cny而非price，避免后续多币种时类型混乱 - 出发日期字段必须是
DATE类型（不是VARCHAR），否则无法用 MySQL 的BETWEEN做范围查询
支付回调必须校验签名且做幂等处理
微信/支付宝回调地址暴露在公网，攻击者可伪造通知。Beego 的 context.Input.Param() 不能直接信任，所有参数需经签名验证后才进入业务逻辑。
- 验签失败直接返回
400，不要调用FinishOrder()或修改数据库 - 用 Redis 存储已处理的
out_trade_no，过期时间设为 24 小时，防止重复回调导致多次发货 - 回调中不要执行耗时操作（如发短信、调物流接口），改为写入消息队列（如 NSQ）异步处理
真正卡住进度的，永远是「订单状态流转是否覆盖所有异常分支」和「退款时如何还原库存」这类细节。Beego 只负责把 HTTP 请求转成 Go 函数调用，剩下的得靠你对旅游行业规则的理解，而不是框架文档。
