完善本地质量门禁与资金链路测试

docs/business-rules.md

@@ -0,0 +1,33 @@
+# 业务规则
+
+## 商品
+
+- 用户完成登录和实名认证后才能发布租赁商品。
+- 商品提交审核并通过后才可公开上架；处于交易中的商品不能被另一订单锁定。
+- 主动下架、交易离架、异常和封存是不同状态，必须保留状态事件。
+
+## 订单
+
+- 创建订单后进入待支付；支付成功后进入待交接并锁定商品。
+- 号主提交交接信息，租客确认后开始计算租期。
+- 租客归还后进入结账协商，双方确认或客服仲裁后完成结算。
+- 订单状态、交接状态和结算状态共同描述流程，禁止仅修改其中一个字段绕过状态机。
+
+## 支付与退款
+
+- 金额均使用整数分，支付单和退款单必须具有唯一业务单号。
+- 渠道通知必须先验签，再按幂等规则推进本地状态。
+- 已进入终态的支付或退款记录不能被迟到通知回退。
+- 人工退款、关闭订单、封存订单和仲裁退款的业务语义不同，均需审计记录。
+
+## 钱包与提现
+
+- 钱包区分可用余额和冻结余额，每次变更必须产生流水。
+- 创建提现申请时，可用余额转为冻结余额；取消或拒绝时原额返还。
+- 审核通过后只有确认打款才能最终扣减冻结余额，重复审核或重复确认必须被拒绝。
+
+## 管理操作
+
+- 管理后台使用独立认证和 RBAC 权限。
+- 关闭、退款、封存、异常、仲裁和余额调整等高风险操作必须写入审计日志。
+- 客服只能通过服务端返回的可用动作执行订单状态转换。

docs/database.md

@@ -0,0 +1,25 @@
+# 数据库设计
+
+## 设计原则
+
+- MySQL 8.4 是生产事实源，Redis 只保存限流、验证码、会话辅助和缓存数据。
+- 金额统一以 `*_cent` 的整数分存储；数量和比例字段按业务精度单独定义。
+- 核心写入通过 GORM 事务完成，钱包账户更新使用行锁并同步写入不可变流水。
+- 表结构由 `backend/migrations` 下的 Goose 迁移管理，应用启动不自动修改生产表结构。
+
+## 核心领域
+
+- 用户与权限：`users`、`admin_users`、角色、权限及关联表。
+- 商品：租赁商品、账号、资产截图、审核记录和状态事件。
+- 订单：租赁订单、交接记录、结账协商、过程事件和申诉。
+- 资金：支付单、退款单、钱包账户、钱包流水、收款账号和提现申请。
+- 运营：系统配置、公告、通知、聊天、二维码池、推送规则和撞车商品。
+
+## 一致性约束
+
+- 下单时在事务内锁定可租商品，避免重复出租。
+- 支付状态、订单状态和商品状态在同一业务事务内推进。
+- 钱包每次余额变化必须生成对应流水，提现在待审核阶段将可用余额转为冻结余额。
+- 支付通知和业务单号使用唯一索引实现幂等。
+
+索引、慢查询、连接池和备份恢复细则见[数据库 SQL 约束与运维](数据库SQL约束与运维.md)。

docs/project-plan.md

@@ -0,0 +1,23 @@
+# 项目计划
+
+## 产品目标
+
+HFB Sys 面向《三角洲行动》账号租赁，提供从商品发布、审核、下单、支付、账号交接、租用、归还、结账到申诉仲裁的闭环，并支持平台代管账号和撞车商品交易。
+
+## 当前阶段
+
+系统已经进入生产运营与稳定性建设阶段。主流程、管理后台、支付渠道、财务统计、消息通知、对象存储和备份恢复均已落地，后续工作以资金正确性、自动化回归和运维可观测性为主。
+
+## 迭代顺序
+
+1. 资金链路：支付回调幂等、退款、钱包余额守恒、提现审核和结算测试。
+2. 稳定性：真实 MySQL E2E、就绪探针、超时任务和恢复演练。
+3. 可维护性：拆分大型前端页面和后端路由组装文件。
+4. 体验：根据运营数据优化商品筛选、订单操作和客服工作台。
+
+## 发布标准
+
+- `./scripts/check.sh` 全部通过。
+- 数据库迁移同时具备 Up/Down，并通过 SQL 门禁。
+- 涉及金额或状态机的变更必须包含回归测试。
+- 生产部署后 `/health/ready` 返回 200，关键下单、支付查询和后台登录完成冒烟验证。

docs/代码质量改进计划.md

@@ -1,643 +1,55 @@
 # HFB Sys 代码质量改进计划
 
-## 文档说明
+## 当前基线
 
-本文档记录了项目代码审查发现的问题和优化计划。
+更新时间：2026-09-02。
 
-**生成时间**: 2026-06-10  
-**项目版本**: refactor/features-architecture 分支
+- 后端约 374 个 Go 文件、6.6 万行代码，64 个测试文件。
+- 前端约 249 个 Vue/TypeScript 文件、8.4 万行代码，7 个测试文件、32 个测试；大型页面样式已外置，订单详情 setup 已独立为 composable 目录中的脚本模块。
+- 数据库使用 61 个 Goose 迁移文件，SQL 约束由 `scripts/check-sql-guard.sh` 检查。
+- 后端总语句覆盖率基线为 30%；核心模块门禁为 order 40%、payment 20%、wallet 34%、withdrawal 30%。
+- 前端支付、钱包、提现和订单展示目标文件已建立 V8 覆盖率门禁：语句 80%、分支 70%、函数 80%、行 80%。
+- Vue 页面大小门禁为 1800 行，`scripts/check-vue-size.sh` 在本地检查中执行，防止大型 SFC 回涨；订单详情页的指标、支付流水和展示工具已拆出独立模块。
+- Repository 已普遍传递请求 Context；当前约 376 处 GORM `WithContext` 调用。
 
----
+## 已落地门禁
 
-## 📊 当前状态
+本地和部署前统一运行：
 
-### 代码规模
-- **后端**: ~28,000 行 Go 代码，122 个模块文件
-- **前端**: ~46,000 行 Vue/TypeScript 代码
-- **数据库**: 876 行 SQL 初始化脚本，114 个索引
-- **测试覆盖率**: 
-  - 后端约 10%（12 个测试文件）
-  - 前端接近 0%（仅 2 个测试文件）
-
-### 测试覆盖率详情
-
-| 模块 | 覆盖率 | 状态 |
-|------|--------|------|
-| realname | 28.2% | ⚠️ 需改进 |
-| listing | 11.1% | 🔴 严重不足 |
-| wallet | 11.0% | 🔴 严重不足 |
-| payment | 8.9% | 🔴 严重不足 |
-| dispute | 8.8% | 🔴 严重不足 |
-| order | 7.7% | 🔴 严重不足 |
-| paymentconfig | 2.2% | 🔴 严重不足 |
-| adminuser | 0.7% | 🔴 严重不足 |
-
----
-
-## 🔴 严重问题（需要尽快处理）
-
-### 1. 测试覆盖率严重不足 ⚠️
-
-**现状**：
-- 核心金融模块（payment, wallet, order）测试覆盖率低于 12%
-- 复杂的订单状态机、结算逻辑、退款流程缺少测试保护
-- 前端几乎没有单元测试
-
-**风险**：
-- 金融相关的钱包、支付、退款逻辑出错会导致资金损失
-- 重构时容易引入 bug，没有安全网
-- 订单状态转换错误会导致业务流程异常
-
-**改进计划**：
-- ✅ **已完成** (2026-06-10 第一批)：
-  - 为 wallet 模块补充 Service 层测试（8 个测试用例）
-  - 为 order 模块补充 Service 层测试（11 个测试用例）
-  - 为 payment 模块补充 Service 层测试（10 个测试用例）
-  
-- ✅ **已完成** (2026-06-10 第二批)：
-  - 为 wallet.Repository 补充核心业务逻辑测试（14 个逻辑测试 + 9 个集成测试）
-  - 为 order.Repository 补充测试（11 个集成测试）
-  - 为 payment.Repository 补充测试（18 个集成测试）
-  
-- 🔄 **进行中**：
-  - [ ] 为 wallet.Repository 补充更多集成测试
-    - [ ] 并发场景测试（账户锁定）
-    - [ ] Withdraw 提现测试
-    - [ ] AdminLedger 管理员账本查询测试
-  
-  - [ ] 为 order.Repository 补充更多集成测试
-    - [ ] Pay 支付状态转换测试
-    - [ ] SubmitHandoff/ConfirmReceive 交接流程测试
-    - [ ] CounterCheckout 反价逻辑测试
-  
-  - [ ] 为 payment.Repository 补充更多集成测试
-    - [ ] Start 支付单创建与复用测试
-    - [ ] StartRefund 退款流程测试
-    - [ ] HandleNotify 支付回调处理测试
-
-- 📅 **计划中**（1-2 周内完成）：
-  - [ ] 前端关键组件测试
-    - [ ] 支付组件单元测试
-    - [ ] 钱包组件单元测试
-    - [ ] 订单流程 E2E 测试
-  
-  - [ ] 集成测试扩展
-    - [ ] 完整租号流程测试（发布→下单→支付→交接→归还→结算）
-    - [ ] 退款流程测试
-    - [ ] 仲裁流程测试
-
-**目标**：
-- 短期（1 个月内）：核心模块测试覆盖率达到 **60%**
-- 中期（3 个月内）：整体测试覆盖率达到 **70%**
-- 长期：建立 CI/CD 测试流程，强制测试覆盖率不低于 60%
-
----
-
-### 2. 缺少 Context 超时控制 🚨
-
-**现状**：
-- 122 个模块文件中只有 8 个使用 `context.Context`
-- 数据库查询、HTTP 调用、外部 API（支付、短信、实名）都没有超时控制
-
-**风险**：
-- 数据库慢查询会导致 goroutine 泄漏
-- 外部 API 超时会拖垮整个服务
-- 无法实现请求级别的超时控制和取消机制
-
-**改进计划**：
-- 📅 **Week 1**：
-  - [ ] 为所有 Repository 方法签名添加 `ctx context.Context` 参数
-  - [ ] 更新 Service 层传递 context
-  - [ ] 在 handler 层从 `c.Request.Context()` 获取 context
-
-- 📅 **Week 2**：
-  - [ ] 为数据库操作添加超时控制
-    ```go
-    ctx, cancel := context.WithTimeout(ctx, 5*time.Second)
-    defer cancel()
-    return r.db.WithContext(ctx).Create(...)
-    ```
-  
-  - [ ] 为外部 API 调用添加超时控制
-    - 支付渠道调用：10 秒超时
-    - 短信服务：5 秒超时
-    - 实名认证：10 秒超时
-
-**示例代码**：
-```go
-// 修改前
-func (r *Repository) Create(userID uint64, req CreateRequest) (*OrderDTO, error) {
-    return r.db.Transaction(func(tx *gorm.DB) error {
-        // ...
-    })
-}
-
-// 修改后
-func (r *Repository) Create(ctx context.Context, userID uint64, req CreateRequest) (*OrderDTO, error) {
-    ctx, cancel := context.WithTimeout(ctx, 5*time.Second)
-    defer cancel()
-    
-    return r.db.WithContext(ctx).Transaction(func(tx *gorm.DB) error {
-        // ...
-    })
-}
+```bash
+./scripts/check.sh
 ```
 
----
+门禁包含：
 
-### 3. 代码文件过大，职责不清 📦
+1. SQL 迁移约束与完整性检查。
+2. `go vet`、Go 全量构建、测试和覆盖率基线。
+3. Prettier、ESLint、Vue/TypeScript 类型检查。
+4. Vitest 和 Vite 生产构建。
 
-**现状**：
-- `listing/repository.go`: **1731 行**
-- `payment/repository.go`: **1282 行**
-- `chat/repository.go`: **1155 行**
-- 平均文件行数：**184 行**（偏高，建议 150 行以下）
+本地门禁通过 `scripts/check.sh` 统一执行；需要完整租赁链路时，在本地 MySQL 8.4 上设置 `HFB_E2E_DSN` 运行 E2E。覆盖率门禁采用“只能提高、不能回退”的基线策略，新增测试后应同步上调阈值。
 
-**问题**：
-- 单个文件包含太多逻辑，难以维护和测试
-- 违反单一职责原则
-- 代码复用困难
+## 后续重点
 
-**改进计划**：
-- 📅 **Week 3-4**：
-  
-  **listing 模块拆分**：
-  ```
-  listing/
-  ├── repository.go       # 核心仓储（保留 Create/Update/Delete）
-  ├── query.go            # 查询逻辑（List/Detail/Search）
-  ├── review.go           # 审核逻辑（SubmitReview/Approve/Reject）
-  └── cache.go            # 缓存逻辑（PublicZoneCount）
-  ```
-  
-  **payment 模块拆分**：
-  ```
-  payment/
-  ├── repository.go       # 核心仓储
-  ├── refund.go           # 退款逻辑（StartRefund/QueryRefund）
-  ├── channel.go          # 渠道适配（lakala/leshua/mock）
-  └── notify.go           # 回调处理（HandleNotify）
-  ```
-  
-  **chat 模块拆分**：
-  ```
-  chat/
-  ├── repository.go       # 核心仓储
-  ├── message.go          # 消息逻辑（Send/List/MarkRead）
-  └── websocket.go        # WebSocket 连接管理
-  ```
+### P0：资金正确性
 
----
+- 扩充支付通知乱序、重复回调和退款重试测试。
+- 扩充钱包并发入账、提现审核竞争和事务回滚测试。
+- 保持金额使用整数分存储，禁止业务层使用浮点数累计金额。
 
-## 🟡 重要问题（影响性能和可维护性）
+### P1：前端回归保护
 
-### 4. 缺少接口抽象，模块耦合严重
+- 为支付收银台、订单操作、提现和后台财务组件增加测试。
+- 优先测试状态转换、权限可见性和请求参数，不追求低价值快照数量。
+- 逐步建立前端覆盖率基线。
 
-**现状**：
-```go
-// order/repository.go 直接依赖具体实现
-type Repository struct {
-    db         *gorm.DB
-    chatRepo   *chat.Repository     // 直接依赖
-    refundFunc RefundFunc           // 通过函数注入
-}
-```
+### P1：结构治理
 
-**问题**：
-- 难以进行单元测试（无法 mock 依赖）
-- 模块间耦合紧密，修改一个模块可能影响其他模块
-- 依赖注入通过 `SetXxx` 方法，容易忘记初始化
+- 将大型管理页面拆成展示组件、操作对话框和 composable。
+- 将路由组装按公开、用户、卖家、管理员领域拆分，保持 `router.New` 只负责依赖组装。
+- 单次拆分必须保持接口、路由名称和用户行为不变。
 
-**改进方案**：
-```go
-// 定义接口解耦
-type ChatService interface {
-    CreateOrderChat(ctx context.Context, orderID uint64) error
-}
+### P2：可观测性
 
-type RefundService interface {
-    Refund(ctx context.Context, orderID uint64, amount int64, bizType, remark string) error
-}
-
-type Repository struct {
-    db         *gorm.DB
-    chatSvc    ChatService
-    refundSvc  RefundService
-}
-
-func NewRepository(db *gorm.DB, chatSvc ChatService, refundSvc RefundService) *Repository {
-    return &Repository{
-        db:        db,
-        chatSvc:   chatSvc,
-        refundSvc: refundSvc,
-    }
-}
-```
-
-**改进计划**：
-- 📅 **Week 5-6**：
-  - [ ] 定义核心接口（ChatService, RefundService, WalletService）
-  - [ ] 重构 Repository 依赖注入
-  - [ ] 更新 router 初始化代码
-
----
-
-### 5. 数据库查询存在性能隐患
-
-**现状**：
-- 数据库索引定义相对较少（114 个索引，20+ 张表）
-- 部分复杂查询缺少索引覆盖
-- 缺少慢查询监控和分析
-
-**具体问题**：
-```sql
--- adminfinance/repository.go 中的财务汇总查询
-SELECT ... FROM rental_orders AS ro
-JOIN order_checkouts AS oc ON oc.order_id = ro.id
-LEFT JOIN (...) AS w ON w.order_id = ro.id  -- 子查询可能很慢
-WHERE ro.settled_at >= ? AND ro.settled_at <= ?
-```
-
-**改进计划**：
-- 📅 **Week 7**：
-  - [ ] 审查所有复杂查询，使用 `EXPLAIN` 分析
-  - [ ] 补充缺失的索引：
-    ```sql
-    -- 订单结算查询优化
-    CREATE INDEX idx_rental_orders_settled_at_status 
-    ON rental_orders(settled_at, settlement_status);
-    
-    -- 财务流水查询优化
-    CREATE INDEX idx_wallet_ledger_user_created 
-    ON wallet_ledger(user_id, created_at DESC);
-    
-    -- 支付订单查询优化
-    CREATE INDEX idx_payment_orders_biz_status 
-    ON payment_orders(biz_type, status, created_at DESC);
-    ```
-  
-  - [ ] 对复杂统计查询考虑预计算方案
-    - 每日财务汇总定时任务（凌晨 1 点）
-    - 用户钱包余额缓存（Redis）
-    - 订单统计数据缓存（5 分钟 TTL）
-
-- 📅 **Week 8**：
-  - [ ] 启用慢查询日志（记录 > 1 秒的查询）
-  - [ ] 建立慢查询分析流程
-  - [ ] 优化 TOP 10 慢查询
-
----
-
-### 6. 缺少 API 限流和熔断机制
-
-**现状**：
-- 只有短信验证码有简单的限流（`ErrCodeRateLimited`）
-- **没有全局 API 限流**
-- **没有熔断机制**保护外部依赖（支付渠道、短信服务）
-
-**风险**：
-- 恶意攻击会拖垮服务
-- 外部服务故障会级联影响整个系统
-- 无法防止暴力破解
-
-**改进计划**：
-- 📅 **Week 9**：
-  
-  **添加全局限流中间件**：
-  ```go
-  import "github.com/ulule/limiter/v3"
-  
-  func RateLimitMiddleware() gin.HandlerFunc {
-      rate := limiter.Rate{
-          Period: time.Minute,
-          Limit:  100, // 每分钟 100 次请求
-      }
-      store := memory.NewStore()
-      middleware := mgin.NewMiddleware(limiter.New(store, rate))
-      return middleware
-  }
-  ```
-  
-  **添加熔断器保护外部服务**：
-  ```go
-  import "github.com/sony/gobreaker"
-  
-  type PaymentChannelWithBreaker struct {
-      channel channelClient
-      breaker *gobreaker.CircuitBreaker
-  }
-  
-  func NewPaymentChannel(channel channelClient) *PaymentChannelWithBreaker {
-      breaker := gobreaker.NewCircuitBreaker(gobreaker.Settings{
-          Name:        "payment_channel",
-          MaxRequests: 3,
-          Timeout:     10 * time.Second,
-          ReadyToTrip: func(counts gobreaker.Counts) bool {
-              failureRatio := float64(counts.TotalFailures) / float64(counts.Requests)
-              return counts.Requests >= 3 && failureRatio >= 0.6
-          },
-      })
-      return &PaymentChannelWithBreaker{channel: channel, breaker: breaker}
-  }
-  ```
-
-- 📅 **限流策略**：
-  - 全局：100 req/min per IP
-  - 登录接口：5 req/min per IP
-  - 短信发送：1 req/min per phone
-  - 支付接口：10 req/min per user
-  - 文件上传：20 req/hour per user
-
----
-
-### 7. 前端错误处理不统一
-
-**现状**：
-- 4 个 Vue 文件中仍有 `console.log/error` 调试代码
-- 错误处理分散在各个组件中
-- 缺少全局错误拦截和统一提示
-
-**改进计划**：
-- 📅 **Week 10**：
-  
-  **统一 HTTP 错误处理**：
-  ```typescript
-  // shared/utils/http.ts
-  import { ElMessage } from 'element-plus'
-  
-  axios.interceptors.response.use(
-    response => response,
-    error => {
-      const message = error.response?.data?.message || '请求失败'
-      ElMessage.error(message)
-      
-      // 统一错误上报（生产环境）
-      if (import.meta.env.PROD) {
-        errorReporter.report({
-          message,
-          stack: error.stack,
-          url: error.config?.url,
-          method: error.config?.method,
-        })
-      }
-      
-      return Promise.reject(error)
-    }
-  )
-  ```
-  
-  **清理调试代码**：
-  - [ ] 移除所有 `console.log` 调试代码
-  - [ ] 添加 ESLint 规则禁止 `console.log`
-  - [ ] 使用统一的日志工具（开发环境）
-
----
-
-## 🟢 改进建议（提升代码质量）
-
-### 8. 日志记录不完整
-
-**现状**：
-- 有基础日志框架（zap）和请求日志中间件
-- 但业务日志记录不充分
-- 缺少关键业务节点的日志追踪
-
-**改进建议**：
-```go
-// 为关键业务操作添加结构化日志
-logger.Info("order paid successfully",
-    zap.Uint64("order_id", orderID),
-    zap.Uint64("user_id", userID),
-    zap.Int64("amount_cent", amount),
-    zap.String("payment_no", paymentNo),
-    zap.String("provider", provider),
-)
-
-logger.Warn("refund failed",
-    zap.Uint64("order_id", orderID),
-    zap.Int64("amount_cent", amount),
-    zap.String("reason", reason),
-    zap.Error(err),
-)
-```
-
-**补充日志点**：
-- [ ] 订单支付成功/失败
-- [ ] 退款申请/成功/失败
-- [ ] 账户交接关键节点
-- [ ] 仲裁处理结果
-- [ ] 钱包余额变更（大额）
-- [ ] 系统配置修改
-
----
-
-### 9. 配置管理可以改进
-
-**现状**：
-- 配置都通过环境变量管理
-- 缺少配置验证
-- 部分配置硬编码在代码中
-
-**改进方案**：
-```go
-// 添加配置验证
-func (c Config) Validate() error {
-    if c.JWTSecret == "change-me" {
-        return errors.New("JWT_SECRET must be set in production")
-    }
-    if c.AppEnv == "production" && c.SMS.Provider == "mock" {
-        return errors.New("SMS provider cannot be mock in production")
-    }
-    if c.AppEnv == "production" && c.Realname.Provider == "mock" {
-        return errors.New("Realname provider cannot be mock in production")
-    }
-    return nil
-}
-
-// 在 main.go 中调用
-cfg := config.Load()
-if err := cfg.Validate(); err != nil {
-    log.Fatal("配置验证失败:", err)
-}
-```
-
-**支持配置文件**：
-- [ ] 支持 `config.yaml` 作为环境变量补充
-- [ ] 支持多环境配置文件（dev/staging/prod）
-- [ ] 敏感配置仍使用环境变量
-
----
-
-### 10. 前端共享逻辑可以进一步抽象
-
-**现状**：
-- `shared/utils` 目录已经做了不错的抽象
-- 但部分工具函数文件过大（`listingDisplay.ts` 11KB、`pricing.ts` 11KB）
-
-**拆分建议**：
-```
-shared/utils/
-├── listing/
-│   ├── display.ts       # 展示相关
-│   ├── format.ts        # 格式化函数
-│   └── filters.ts       # 过滤逻辑
-├── pricing/
-│   ├── pricing.ts       # 价格计算
-│   ├── discount.ts      # 折扣计算
-│   └── commission.ts    # 佣金计算
-└── ...
-```
-
----
-
-### 11. 缺少文档和注释
-
-**现状**：
-- 代码注释较少
-- 没有完整的架构文档
-- API 文档依赖 Swagger
-
-**改进计划**：
-- [ ] 补充架构文档
-  - [ ] 数据库设计文档（`database.md`）
-  - [ ] 订单状态机文档
-  - [ ] 支付流程文档
-  - [ ] 结算规则文档
-  
-- [ ] 补充开发者指南
-  - [ ] 如何添加新功能模块
-  - [ ] 如何编写测试
-  - [ ] 如何部署到生产环境
-  
-- [ ] 生成并维护 API 文档
-  - [ ] 完善 Swagger 注释
-  - [ ] 自动生成 API 文档
-
----
-
-### 12. 缺少监控和告警
-
-**现状**：
-- 有基础日志（按天切分）
-- 有审计日志
-- **但没有性能监控、错误追踪、告警机制**
-
-**改进方案**：
-
-**集成监控工具**：
-- Prometheus + Grafana（应用监控）
-- Sentry（错误追踪）
-- OpenTelemetry（链路追踪，可选）
-
-**关键指标**：
-- API 响应时间（P95, P99）
-- 错误率
-- 订单支付成功率
-- 数据库慢查询
-- 外部 API 调用成功率
-
-**告警规则**：
-- API 错误率 > 5%
-- 支付成功率 < 95%
-- 数据库慢查询 > 10 次/分钟
-- 外部服务调用失败率 > 10%
-
----
-
-## 📊 优先级和时间计划
-
-### 🔥 立即处理（已完成）
-- ✅ 为核心金融模块补充单元测试（wallet, order, payment Service 层）
-
-### ⚡ 短期优化（1-2 周）
-- **Week 1-2**: 添加 Context 超时控制
-- **Week 3-4**: 拆分大文件（listing/payment/chat repository）
-- **Week 5-6**: 引入接口抽象，降低模块耦合
-- **Week 7-8**: 补充数据库索引，优化慢查询
-
-### 🎯 中期改进（1-2 个月）
-- **Week 9**: 添加 API 限流和熔断机制
-- **Week 10**: 统一前端错误处理
-- **Week 11-12**: 补充 Repository 层集成测试
-- **Week 13-14**: 补充前端组件测试
-- **Week 15-16**: 添加监控和告警系统
-
-### 🌟 长期目标（3-6 个月）
-- 建立 CI/CD 测试流程
-- 测试覆盖率达到 70%+
-- 完善技术文档
-- 性能优化（P95 响应时间 < 200ms）
-
----
-
-## 📈 成功指标
-
-### 代码质量
-- [ ] 测试覆盖率 ≥ 60%（核心模块 ≥ 70%）
-- [ ] 平均文件行数 < 150 行
-- [ ] 代码重复率 < 5%
-
-### 性能指标
-- [ ] API P95 响应时间 < 200ms
-- [ ] API P99 响应时间 < 500ms
-- [ ] 数据库慢查询 < 5 次/分钟
-
-### 可靠性指标
-- [ ] API 可用性 > 99.9%
-- [ ] 错误率 < 0.1%
-- [ ] 支付成功率 > 99%
-
----
-
-## 🎉 已完成的改进
-
-### 2026-06-10（第一批）
-- ✅ 为 `wallet` 模块补充 Service 层单元测试（8 个测试用例）
-- ✅ 为 `order` 模块补充 Service 层单元测试（11 个测试用例）
-- ✅ 为 `payment` 模块补充 Service 层单元测试（10 个测试用例）
-- ✅ 为 `wallet` 模块补充 Repository 逻辑测试（14 个测试用例）
-- ✅ 为 `wallet` 模块补充 Repository 集成测试（9 个测试用例）
-- ✅ 所有新增测试通过验证
-- ✅ 测试覆盖率基线建立：
-  - wallet: 11.0% → **36.1%**（提升 25%）
-  - order: 7.7%
-  - payment: 8.9%
-
-### 2026-06-10（第二批 - Week 1-2 完成）
-- ✅ 为 `order` 模块补充 Repository 集成测试（11 个测试用例）
-  - 订单创建验证（商品状态、不能租自己的商品）
-  - 订单定价计算测试
-  - 结账结算计算测试（全额租用、扣押金、额外消耗）
-  - 状态常量验证测试
-  - 订单时长计算测试
-- ✅ 为 `payment` 模块补充 Repository 集成测试（18 个测试用例）
-  - 支付单复用逻辑测试
-  - 支付状态转换测试
-  - 退款业务类型覆盖测试
-  - 支付金额验证测试
-  - 支付渠道验证测试
-  - Mock 模式判断测试
-  - 钱包充值开关测试
-- ✅ 测试覆盖率提升：
-  - wallet: **36.1%**（保持）
-  - order: 7.7% → **10.2%**（提升 2.5%）
-  - payment: **8.9%**（保持）
-
-### 测试统计（Week 1-2 完成后）
-- **测试文件总数**: 16 个
-- **测试用例总数**: 103 个（估算）
-  - wallet: 34 个
-  - order: 28 个（17 + 11）
-  - payment: 41 个（23 + 18）
-- **所有测试通过率**: 100%
-
----
-
-## 📝 备注
-
-- 本文档是活文档，随着项目演进持续更新
-- 每完成一项改进，更新进度标记（✅）
-- 定期回顾（每 2 周），调整优先级
-
-**文档维护者**: Claude Code  
-**最后更新**: 2026-06-10
+- 区分 `/health` 存活探针和 `/health/ready` 就绪探针。
+- 持续观察慢查询、退款重试、订单超时任务和备份恢复演练结果。