3.5 KiB
消费机创建订单分段耗时
外部接口 /hard/hard-api/ad/create-order 对应 hard 服务内部
POST /hard-api/ad/create-order。本次诊断仅观察该请求，不改变请求协议、
事务注解、分布式锁、支付顺序、重试和返回值。
日志策略与开销
- 通过
System.nanoTime()和请求内存中的阶段表计时，不新增 SQL、Redis 或 Feign 请求。 - 正常且小于 1 秒的请求不新增摘要；慢请求、失败及阶段内被业务处理的异常输出一条 warning。
- 摘要在过滤器链返回或抛错后统一生成，不在扣款写事务中逐阶段输出日志。
- 专用 Logback 异步队列容量为 256，
neverBlock=true。队列满时丢弃诊断摘要，不等待落盘。 - 使用已有
debug.log文件；不写入 DTO、人员资料、金额、令牌、付款码、图片或异常消息。
计时与内存分配存在少量开销，不能承诺零开销。异步队列优先保障请求返回， 日志管道持续拥堵时可能缺少部分诊断记录。
取日志与匹配
部署包含 Java 代码和 logback-spring.xml 改动的 hard 服务后，在 debug.log
搜索 |终端支付耗时|。按 androidOrderCode 与消费机的 |支付耗时| 摘要、
原有订单 SQL 对齐；同号重试可通过不同的 trace 区分请求。
outcome:failed 是请求未正常完成，不能单凭这一字段判断钱包是否已经扣款；
仍需按原有订单对账逻辑确认。旁路通知或证据登记异常被业务自行处理时，
请求可能保持 outcome:success，异常类型保存在 stageErrorTypes 中。
主要阶段
| 字段 | 范围 |
|---|---|
pre_controller |
请求监听器开始至 Controller 进入，含期间租户检查、认证、解析及校验 |
controller |
Controller 参数整理、Service 调用和返回对象创建 |
redis.lock / redis.unlock |
原有 Redis 加锁、持锁检查及解锁 |
idempotency.lookup / idempotency.validate |
原订单查询及重复请求一致性校验 |
prepare |
下单准备整体，含下面的远程及本地查询 |
prepare.merchant / prepare.hardware |
商户远程查询、设备本地查询 |
prepare.user / prepare.wallet / prepare.cart |
用户、钱包及商品计价准备 |
transaction |
原有代理事务调用，包含事务开始、提交及同步 afterCommit |
db.cart / db.orderInsert |
购物车和订单写入 |
wallet.debit |
原有钱包扣款远程调用 |
db.orderPaid / db.cartPaid |
已支付状态更新 |
afterCommit.evidence |
原有同步人脸证据元数据登记 |
postCommit.notify |
原有提交后打印/播报分支 |
stagesInclusiveMs 单位为毫秒，父阶段包含子阶段，不能直接相加。
其他支付方式仍按原逻辑执行，日志可出现核销、库存及第三方支付阶段。
时间边界
监听器在 Servlet 过滤器之前记录起点，专用过滤器在原有租户过滤器之后、 安全过滤器之前绑定请求追踪，不调整已有过滤器顺序。 若请求在更早的租户过滤器中直接拒绝，尚未进入计时过滤器，则不会产生本摘要。
totalMs 截止过滤器链返回，不是客户端端到端耗时；不覆盖网关和入站网络、
容器调用请求监听器前的排队、最后的响应传输，以及客户端本地处理。
因此“客户端 4500ms、服务摘要 200ms”只能证明还需排查摘要计时区间之外的等待，
不能直接认定为 Flutter 程序卡顿。