Homestay

实现server/internal 按 auth、user、homestay、room、order、payment 划分领域包，各自保留 model、repository、service 和 handler 边界；Gin router 只负责组装依赖和路由。

价值在单体部署复杂度可控的前提下，把房态、订单和支付的业务规则集中在明确的服务边界中，后续仍有拆分或替换实现的空间。

实现金额统一使用 int64 分，订单保存房源、房型和每日价格快照；Redis 只保存带版本号的房态日历，缓存异常时 fail-open 回源 MySQL。

价值避免浮点金额误差和缓存写入失败导致的库存错乱，也让支付金额校验可以对照订单持久化数据完成。

实现room_inventory_daily 为每个房型和日期保存 total_stock、locked_stock、sold_stock、daily_price 和 closed；退房日按 checkout exclusive 处理，最多预览 93 天、预订 30 晚。

价值价格和库存可以随日期变化，周末价、关闭日期和跨夜预订都能在服务端以同一套数据模型校验。

实现orders 使用 user_id + idempotency_key 联合唯一约束；Order Service 在事务中先查既有订单，遇到并发唯一键竞争时再读取已创建订单并返回。

价值网络重试、按钮连击或客户端超时不会轻易产生重复订单，幂等语义由数据库约束和服务逻辑共同兜底。

实现创建、取消和支付确认都会按日期升序锁定库存行，使用 SELECT ... FOR UPDATE 检查 available stock，再移动 locked_stock / sold_stock；更新后还检查 RowsAffected 是否符合预期。

价值并发预订同一房型时由 MySQL 串行化关键库存判断，固定锁顺序也降低了跨日期锁竞争形成死锁的概率。

实现房态缓存 key 包含 roomTypeID、版本、起止日期；库存发生变化后 Redis INCR 版本号，旧 key 自然失效，读写缓存失败不会阻断主交易。

价值不需要枚举并删除所有日期区间 key，就能让订单创建、取消和支付确认后的房态读取回到新版本。

实现Payment Service 通过 WechatGateway 抽象生产支付创建与通知验签；真正的库存扣减仍由本地确认事务完成，并以订单金额、商户号、AppID 和交易状态做校验。

价值第三方支付 SDK 不会直接改写业务库存，回调重复、金额异常或订单已过期时都有明确的本地状态判断。

实现SQL migration 通过 go:embed 和 schema_migrations 记录版本，生产环境单独运行 migrate；API 和 worker 分别部署，避免把过期订单扫描塞进 HTTP 请求进程。

价值数据库结构变更和业务进程启动解耦，过期回收任务也能拥有独立的运行与扩容边界。