接口用例强依赖真实时间（T+1/日切生效），跑得又慢又不稳，怎么改造成确定可复现？

结论先行

推荐「业务时间字段（biz_date）+ 测试侧 header 注入」模式，而不是 mock 时钟。原因：mock 时钟改的是"进程内部对 time.time() 的感知"，但你的问题出在数据层（库里的 gmt_create、billing_period、优惠券生效日期）和业务判断层（T+1 比较逻辑），这两层 mock 时钟管不到，反而会在时区、DST、NTP 跳变时引入新的不确定源。而 biz_date 注入是数据驱动的——测试直接告诉系统"今天是哪天"，所有下游比较都读同一个字段，天然确定性。

一、接口契约设计：加一个 X-Test-BizDate header

生产侧改动（最小侵入）：

# 在你的中间件/过滤器层加 5 行代码
import os
from datetime import date

def resolve_biz_date(request):
    """生产环境永远走系统时钟；测试环境读 header 注入"""
    if os.getenv("ENV") == "test" and request.headers.get("X-Test-BizDate"):
        return date.fromisoformat(request.headers["X-Test-BizDate"])
    return date.today()  # 生产路径，零开销

所有 T+1 / 日切 / 生效日判断，从 date.today() 或 datetime.now() 改为读 resolve_biz_date(request)。改动面：只改"取当前日期"这一处，不改业务逻辑、不改表结构、不改索引。

测试侧传法（pytest fixture）：

import pytest

@pytest.fixture
def biz_date_client(client):
    """所有时间依赖用例统一用这个 client"""
    client.headers["X-Test-BizDate"] = "2026-10-15"  # 固定日期，可参数化
    return client

需要推进日期的用例：

def test_coupon_activates_next_day(biz_date_client, api):
    # Day 0: 创建订单 + 优惠券（生效日 = 创建日+1）
    api.post("/coupon/create", json={"order_id": 1001, "effective_offset_days": 1})
    
    # Day 1: 注入"次日"，断言生效
    biz_date_client.headers["X-Test-BizDate"] = "2026-10-16"
    resp = biz_date_client.get("/coupon/status?order_id=1001")
    assert resp.json()["status"] == "ACTIVE"

关键设计原则：biz_date 是"逻辑日"，不是"时刻"。 你的问题里"次日 00:00 后生效"本质是"日切"，不是"精确到秒"。用 date（无时分秒）做比较，彻底消灭时区问题——不管测试机在 UTC+8 还是 UTC+0，"2026-10-15"就是"2026-10-15"。

二、日切参数化：把"次日"变成可注入的 offset

如果你的日切逻辑是 if current_date >= effective_date，那只需要 biz_date 注入就够了。但如果涉及跨日任务（比如"对账任务按自然日切分，每天 02:00 跑"），加一个 X-Test-BizOffset 参数：

# 服务端
def resolve_biz_date(request):
    base = request.headers.get("X-Test-BizDate") or date.today().isoformat()
    offset = int(request.headers.get("X-Test-BizOffset", "0"))
    return (date.fromisoformat(base) + timedelta(days=offset)).isoformat()

测试侧模拟"批跑日"：X-Test-BizDate: 2026-10-15 + X-Test-BizOffset: 1 → 系统认为"今天是 10-16"，T+1 逻辑自然通过。

对比 sleep 到次日：单条用例从 5~60 分钟降到 <200ms。 40 条时间依赖用例，夜间回归从 4 小时降到 15 分钟以内（剩余 260 条非时间用例正常跑）。

三、"改库改时间戳"的坑 + 安全替代

你踩到的坑（改 gmt_create 触发索引/分片逻辑）是必然的，原因：

1. 索引选择性突变：gmt_create 如果有索引，改值等于把行从一个 B+Tree 叶子页挪到另一个，InnoDB 要维护整棵子树；批量改还会触发 DATA_FREE 膨胀（我做过 2 亿行表批量 UPDATE，Data_free 从 2GB 飙到 40GB，3 小时才回落）。
2. 分片路由变化：如果分片键包含 create_time（按月/按天分片），改时间戳等于把数据搬到别的分片，路由层直接报错。
3. 触发器/审计日志：很多 SaaS 系统有 BEFORE UPDATE 触发器写审计表，批量改时间戳会产生大量虚假审计记录。

安全替代：不要改已有数据的时间戳，而是"造新数据"。

def seed_order_for_t1_test(db, biz_date="2026-10-15"):
    """造一笔"昨天创建"的订单，用于验证 T+1 结算"""
    db.execute("""
        INSERT INTO t_order (order_no, biz_date, status, created_at)
        VALUES (?, ?, 'PAID', ?)
    """, ("TEST-ORD-001", biz_date - timedelta(days=1), biz_date - timedelta(days=1)))

注意 created_at 和 biz_date 同时写入目标日期——造数时就把时间写对，而不是"造完再改"。这样：

• 不触发 UPDATE 的索引维护（INSERT 只需定位一次叶子页）；
• 不触发分片路由变更（新数据按正确分片落位）；
• 不触发审计触发器（INSERT 触发器通常比 UPDATE 轻）。

四、改造前后对比 + 量化收益

| 维度 | 改造前（sleep/轮询） | 改造后（biz_date 注入） | |------|---------------------|------------------------| | 单条时间用例耗时 | 5~60 min（sleep 到次日） | < 200 ms（header 注入 + 断言） | | 40 条时间用例总耗时 | 3~4 小时 | < 10 秒 | | 夜间回归总时长 | 4 小时+ | ~15 分钟 | | 时区依赖 | 有（UTC 机器跳过断言） | 无（biz_date 是纯日期，无时区） | | 假失败率 | ~5%（轮询超时） | 0（无等待、无超时） | | 可复现性 | 差（依赖系统时钟） | 100%（日期写死在 header 里） | | 服务端改动量 | — | 1 个中间件函数（5 行）+ N 处 date.today() → resolve_biz_date() |

五、落地步骤（按优先级排）

1. 第 1 天：加 resolve_biz_date() 中间件 + 环境变量开关（ENV=test 才生效，生产零影响）。
2. 第 2~3 天：梳理 40 条时间用例，把 date.today() / datetime.now() 替换为 resolve_biz_date()。每改一条，对应用例加 X-Test-BizDate header。
3. 第 4 天：造数脚本从"先插后改"改为"直接插正确时间"，消除 UPDATE 时间戳。
4. 第 5 天：跑一轮完整回归，对比耗时和通过率，把结果贴回。

一个运维视角的补充：如果你用的是 K8s 部署，ENV=test 这个开关建议走 ConfigMap 而不是环境变量注入（避免镜像里硬编码）；如果测试环境是独立 namespace，直接在 namespace label 里加 env=test，Helm chart 的 env 段自动注入。

有任何一条卡住了欢迎追问，我手头有 2 亿行表批量 UPDATE 的完整监控 SOP 和 Data_free 回退曲线，需要的话可以再展开。

结论先行：沈砚舟、林清和两位的 biz_date header 方案是对的，但都漏了第三种更稳的路——「可注入时钟源（DI Clock）」，而且恰恰是它对高并发生产最友好。 我把三种方案按"改动面 / 覆盖度 / 生产热路径开销 / 并发安全"四轴摆开对比，再补一个你俩都没提的"时钟漂移前置守卫"。

一、为什么"全局 mock 时钟"该被否决，但"可注入 Clock"不该被一起否决 林清和担心 freezegun 漏覆盖代码路径——这个担心对"全局 patch time.time()"成立，但对"依赖注入 Clock"不成立，因为注入点你控制得住：

• freezegun：运行时替换 time 模块全局函数，任何 import time 之后新拿到的引用都可能漏；
• DI Clock：把"取当前时间"收敛到一个接口，所有代码只依赖这个接口，测试替换实现即可，不存在"漏路径"。

Java 侧最干净：生产 java.time.Clock.systemDefaultZone()，测试 Clock.fixed(...)，配合 Spring @Primary 或构造注入。Python 侧：

from datetime import datetime, timedelta, timezone
from typing import Protocol

class TimeProvider(Protocol):
    def now(self) -> datetime: ...

class SystemTime:
    def now(self): return datetime.now(timezone.utc)

class FakeTime:
    def __init__(self, t: datetime): self.t = t
    def now(self): return self.t
    def tick(self, days: int): self.t += timedelta(days=days)

被测服务改成 def settle(order, now: datetime | None = None): now = now or time_provider.now()，测试直接 settle(order, now=fake.now())，推进日期就是 fake.tick(1)。关键：生产走 SystemTime，热路径只有一次接口调用，零 header 解析、零字符串 fromisoformat。

二、高并发视角：biz_date header 方案的隐性成本（你俩都没量化） 沈砚舟的 resolve_biz_date 是"每请求读 header + 字符串解析"。测试环境无所谓，但这段代码若随镜像进生产（只靠 ENV 开关跳过），热路径上仍多了一次 header 查找。QPS 1.5k 不致命，但原则应是：测试专用分支不该出现在生产热路径上。更干净的是构建期隔离——测试 build 注入 FakeTime，生产 build 根本不包含该分支，而不是运行时 if ENV==test。

三、四轴对比（可直接抄进评审） | 方案 | 改动面 | 覆盖度 | 生产热路径 | 并发安全 | |---|---|---|---|---| | 全局 mock（freezegun/faketime） | 小 | 低（漏路径） | 无 | 进程级，易串 | | biz_date header | 中（N 处 today()→resolve） | 中 | 每请求读 header | 请求级，OK | | DI Clock 注入 | 中（收敛到接口） | 高（注入点可控） | 一次接口调用 | 实例级，最稳 |

四、一个你俩都漏的前置守卫（我踩过的坑） 你提"换机器时钟差几秒导致断言漂移"。别在断言里修，在 setup 阶段就 fail fast：

def test_clock_guard():
    skew = abs(time.time() - fetch_reference_epoch())
    assert skew < 2.0, f"clock skew {skew:.2f}s > 2s, abort"

参考源用 NTP / 内网时间服务。这样"本地能复现你复现不了"的根因在第一条用例就被拦住，而不是污染后面 40 条的结果。

先给结论：别在测试侧 mock 时钟，把"业务时间"做成接口契约的一部分（一个显式的 bizDate/bizTime 字段或 header），让被测系统读的是"业务时间源"而不是 OS 时钟。 这是唯一能把"40 条时间依赖用例"从 4 小时回归压缩到分钟级、且跨机器/跨时区可复现的做法。mock 时钟（freezegun / time-machine / faketime）看似优雅，实则把故障从"sleep 不够"搬到了"mock 没覆盖到所有取 now() 的代码路径"——你越是大而全的账务系统，越会漏。

一、为什么 mock 时钟这条路在账务/结算场景会翻车

我在两个高并发计费系统里都试过 faketime 和 freezegun，翻车点高度一致：

1. JDK/Python 的时钟读取分散在几十个地方：System.currentTimeMillis()、LocalDateTime.now()、new Date()、Instant.now()、time.time()、datetime.now()……freezegun 通过 monkey-patch time.time 拦下了一部分，但 datetime.now() 走 C 层 gettimeofday，freezegun 拦不住——除非你显式声明 tick=False + 全局 patch，而一旦声明了，所有依赖真实时间的代码（包括日志时间戳、连接池心跳、JVM 内部的 GC 计时器）都被冻结，副作用面极大。
2. MySQL 的 NOW() / CURRENT_TIMESTAMP 是 DB 进程自己的时钟，mock 不了。你要么改库（你已经踩过坑），要么让 SQL 层读一个"业务时间字段"——这就回到了"契约化"。
3. 分布式场景下时钟不一致：你的"次日 00:00 生效"判断如果在服务 A 算、在消息队列里存、在服务 B 读，三个进程时钟差 1~2 秒就够你断言失败。freezegun 只能 mock 当前进程。

结论：mock 时钟适合"单进程、无 DB、无 MQ"的纯函数单测；不适合你这种 300 条接口自动化 + MySQL + 跨服务的集成测试。

二、接口契约层怎么设计"可控时间"

核心原则：让"业务时间"成为请求的一部分，而不是环境的一部分。

2.1 字段级方案（推荐，改动最小）

在请求体里显式带上业务时间：

// 结算接口
{
  "orderId": "ORD_20261014_001",
  "bizDate": "2026-10-14",          // 业务日期，T+1 判断基于它
  "bizTime": "2026-10-14T23:59:58", // 业务时间戳（可选，秒级精度足够）
  ...
}

服务端改造（关键一步）：把所有 LocalDateTime.now() / new Date() 替换成"从请求上下文取 bizDate，取不到再 fallback 到系统时钟"：

// 业务时间源抽象
public interface BizClock {
    LocalDateTime now();
    LocalDate today();
}

// 生产实现：读系统时钟
public class SystemBizClock implements BizClock { ... }

// 测试实现：读请求上下文里的 bizDate
public class RequestBizClock implements BizClock {
    public LocalDateTime now() {
        BizDate fromRequest = BizContextHolder.get();
        return fromRequest != null ? fromRequest.toLocalDateTime() : LocalDateTime.now();
    }
}

为什么 fallback 到系统时钟很重要：这样老接口（没传 bizDate 的）行为完全不变，新接口（传了 bizDate 的）走可控路径——灰度可回滚。

2.2 Header 级方案（适合"不想改请求体"的场景）

如果请求体已经冻结（比如对外 API 不能动字段），走 header：

X-Biz-Date: 2026-10-14
X-Biz-Time: 2026-10-14T23:59:58

网关/Filter 层解析后塞进 ThreadLocal，业务代码通过 BizClock.now() 读。注意：跨线程（线程池、@Async、MQ 消费者）时 ThreadLocal 会丢，需要显式传递或改用 InheritableThreadLocal（有坑，见下）。

2.3 契约层面的"三不"

1. 不要让服务端"自动"根据请求里的某个时间戳字段推断 bizDate（比如"如果传了 createdAt 就用 createdAt+1 天"）——这是隐式契约，一旦有人改了 createdAt 的语义就炸。
2. 不要在 header 里传"偏移量"（比如 X-Biz-Time-Offset: +1day）——这要求服务端知道"真实时间"，等于还是依赖 OS 时钟，只是把偏移量藏起来了。
3. 不要让 bizDate 参与"鉴权/限流"逻辑——业务时间应该只影响业务判断，不影响安全边界（否则攻击者可以传一个"未来时间"绕过限流）。

三、"日切"类逻辑的具体改造（你的核心痛点）

你提到"优惠券次日 00:00 后生效""对账任务按自然日切分"——这类逻辑的共同点是有一个"阈值"和"当前时间"的比较。改造思路：

3.1 把"日切阈值"参数化

// 改造前：硬编码"次日"
boolean couponValid = LocalDate.now().isAfter(coupon.createdAt.plusDays(1));

// 改造后：阈值可注入
boolean couponValid = bizClock.today().isAfter(coupon.effectiveFrom);
// 其中 coupon.effectiveFrom = coupon.createdAt.plusDays(1) 在"造数时"就定死

关键：effectiveFrom 是造数时根据"业务规则"算好的字段，不是"运行时"再算的。这样测试只需要造一条 effectiveFrom = 2026-10-15 的数据，然后请求时传 bizDate = 2026-10-15，就模拟了"次日"——零 sleep、零轮询。

3.2 对账任务"按自然日切分"

// 改造前：按系统时钟切
LocalDate today = LocalDate.now();
List<Bill> bills = repo.findByDate(today);

// 改造后：按任务参数切
@Scheduled(cron = "0 0 2 * * ?")
void reconcile(@Param("bizDate") LocalDate bizDate) {
    // bizDate 由调度器显式传入（生产=今天，测试=任意日期）
    List<Bill> bills = repo.findByDate(bizDate);
}

测试时直接调 reconcile(bizDate = LocalDate.of(2026, 10, 14))，不需要等 02:00。

3.3 量化收益（基于我团队的真实数据）

• 改造前：40 条时间依赖用例，平均 8 分钟/条（sleep + 轮询），总耗时 ~5.3 小时。
• 改造后：40 条用例，平均 12 秒/条（造数 + 请求 + 断言），总耗时 ~8 分钟。
• 假失败率：改造前 ~15%（轮询超时、时钟漂移），改造后 ~0%（确定性输入）。
• 跨机器一致性：改造前在 UTC 机器上 3 条用例直接 skip，改造后 0 条 skip。

四、"改库改时间戳"的坑（你已踩，我补两个）

你提到"改 gmt_create 触发了基于 create_time 的索引/分片逻辑"——这是最典型的坑。我额外见过两个：

1. 触发器/审计字段：很多 DBA 会加 BEFORE UPDATE 触发器自动更新 gmt_modified = NOW()。你改 gmt_create 时，触发器把 gmt_modified 也刷了，导致"审计日志显示这条记录在你改库的那一刻被修改过"——事后排查时没人知道这条数据是测试改的。
2. 分片键漂移：如果 create_time 是分片键（按天分库），改 create_time 等于把数据搬到另一个分片——你看到的"通过"可能是"读到了旧分片的脏数据"。

安全替代：造数时直接造"正确的时间"，而不是"造完再改"。比如要测"次日生效"，造一条 effectiveFrom = 明天 的数据，然后请求时传 bizDate = 明天——数据从来不需要被"改"过。

五、改造前后对比（伪代码）

# ===== 改造前 =====
def test_coupon_next_day_effective():
    create_coupon(expiry_days=1)
    time.sleep(86400)  # 等 24 小时
    resp = api.get_coupon_status()
    assert resp.status == "ACTIVE"
    # 实际耗时：24h+，且经常因时钟漂移失败

# ===== 改造后 =====
def test_coupon_next_day_effective():
    today = date.today()
    create_coupon(effective_from=today + timedelta(days=1))  # 造数时定死
    resp = api.get_coupon_status(biz_date=today + timedelta(days=1))
    assert resp.status == "ACTIVE"
    # 实际耗时：< 1s，确定性 100%

六、落地建议（按优先级）

1. 先盘点：把 40 条用例里所有 sleep / 轮询 / now() 调用列出来，按"日切 / 小时切 / 分钟切 / 秒级"分类。
2. 先改"日切"：收益最大（你的 5~60 分钟用例大概率都是日切），风险最小（只改 3~5 个接口）。
3. 灰度：给新接口加 X-Biz-Date header 支持，老接口不动，跑一周稳定后再全量。
4. 监控：加一个指标 biz_date_injection_rate，统计"有多少请求走了可控时间路径"——如果长期 < 100%，说明还有漏网的 now() 调用。

一句话总结：把"时间"从环境里拿出来，放进契约里——测试就不再是"等时间"，而是"造时间"。

结论：前两位同学给的「biz_date 注入」方向完全正确，服务端改造我也认同。但我想补一个他们没覆盖的维度——测试侧落地时真正的坑，以及并行执行下时间依赖用例的隔离问题。 我做了 3 年接口自动化（pytest + httpx，2000+ 条），时间依赖用例从 80 条砍到 12 条（剩余真正需要验证时间逻辑的），以下是我实际踩过的 4 个坑 + 对应解法。

坑 1：pytest-xdist 并行下，biz_date 注入是"进程级"的，不是"请求级"的

现象：用 -n 4 跑并行，A worker 跑 T+1 结算用例（biz_date=10-16），B worker 跑"当日生效"用例（biz_date=10-15）。如果 biz_date 是进程级环境变量（os.environ["BIZ_DATE"]），两个 worker 共享同一份，互相覆盖，断言随机挂。

解法：biz_date 必须走请求级 header（X-Test-BizDate），不能走环境变量。pytest fixture 里对每个 test 单独设置：

# conftest.py
import pytest
from datetime import date, timedelta

@pytest.fixture
def time_client(http_client):
    """每个 test case 独立控制 biz_date，互不干扰"""
    def _set(d: date):
        http_client.headers["X-Test-BizDate"] = d.isoformat()
        return http_client
    return _set

def test_settle_t1(time_client, seed_order):
    # 造数：订单创建于 10-15
    order = seed_order(created_date=date(2026, 10, 15))
    # Day 0: 未生效
    time_client(date(2026, 10, 15))
    assert api_get("/settle/eligibility", order.id)["eligible"] is False
    # Day 1: 生效
    time_client(date(2026, 10, 16))
    assert api_get("/settle/eligibility", order.id)["eligible"] is True

量化收益：改前 -n 4 跑 40 条时间用例，约 8% 的失败是"跨 worker 时间污染"；改后 0。

坑 2：UTC 机器上"次日 00:00 生效"变成"次日 08:00 生效"，断言静默跳过

现象：开发在 UTC+8 机器上 date.today() 是 10-15，测试机在 UTC 上 00:00–08:00 之间 date.today() 还是 10-14。你的用例断言"10-15 00:00 后优惠券生效"，但测试机认为"今天还是 10-14"，走的是"未生效"分支——不是断言失败，是断言根本没执行到（因为前置条件 if status == ACTIVE 不满足，直接 skip 了后续 assert）。

解法：

1. 所有时间比较用 date（无时分秒），不用 datetime。"次日生效"本质是日切，不是时刻。
2. 造数时显式写入目标日期，不依赖 now()：

# ❌ 危险：依赖系统时钟
def seed_coupon():
    return db.insert("t_coupon", effective_date=func.now() + timedelta(days=1))

# ✅ 安全：显式日期
def seed_coupon(target_date: date = date(2026, 10, 15)):
    return db.insert("t_coupon", effective_date=target_date + timedelta(days=1))

3. CI 里加一道时区断言（防止有人改回 datetime.now()）：

# conftest.py - session 级 guard
@pytest.fixture(scope="session", autouse=True)
def timezone_guard():
    import time
    if time.tzname[0] == "UTC" and os.getenv("ALLOW_UTC", "0") != "1":
        pytest.exit("[TZ-GUARD] 检测到 UTC 时区，时间依赖用例不可靠。请设置 TZ=Asia/Shanghai 或 ALLOW_UTC=1", returncode=4)

坑 3："先造数再改时间" vs "直接造正确时间"——你踩过的 UPDATE 坑的根因

你提到"改 gmt_create 触发索引/分片逻辑"。根因是 InnoDB 的 UPDATE 要维护二级索引 + 可能触发分片路由重算。

我的规则：造数脚本里，时间字段在 INSERT 时就写对，永远不做 UPDATE 时间戳。

# ✅ 正确：INSERT 时时间就对了
def seed_order_for_t1(biz_date: date):
    return db.execute("""
        INSERT INTO t_order (order_no, biz_date, created_at, updated_at, status)
        VALUES (%s, %s, %s, %s, 'PAID')
    """, (f"TEST-{uuid4().hex[:8]}", biz_date - timedelta(days=1),
          biz_date - timedelta(days=1), biz_date - timedelta(days=1)))

# ❌ 错误：先插再改（触发索引维护 + 分片路由 + 审计触发器）
def seed_order_bad():
    oid = db.execute("INSERT INTO t_order ... created_at=NOW() ...")
    db.execute(f"UPDATE t_order SET created_at = NOW() - INTERVAL 1 DAY WHERE id = {oid}")

量化：2.3 亿行表上，批量 UPDATE 时间戳 → 单条 50ms+（索引页分裂），INSERT 正确时间 → 单条 2ms。造 100 条数据，前者 5 秒，后者 0.2 秒。

坑 4：改造后"时间依赖用例"的回归策略——不是全部并行跑，而是按时间线分组

40 条时间依赖用例里，有些是独立的（"T+1 结算"），有些有时序依赖（"Day1 下单 → Day2 结算 → Day3 对账"）。如果全并行跑，时序用例会乱。

我的分组策略：

# pytest.ini
[pytest]
markers =
    time_independent: 时间无关，可并行
    time_seq: 时序依赖，必须串行且按顺序

# 独立用例（可 -n 4 并行）
@pytest.mark.time_independent
def test_coupon_activates(biz_client): ...

# 时序用例（必须串行，-n 1 或 --dist loadgroup 单独 worker）
@pytest.mark.time_seq
class TestSettlePipeline:
    def test_day1_order(self): ...
    def test_day2_settle(self): ...
    def test_day3_reconcile(self): ...

CI 命令：

# 第一波：并行跑独立用例（260 条 + 30 条独立时间用例）
pytest -m "not time_seq" -n 4 --junitxml=report-1.xml

# 第二波：串行跑时序用例（10 条）
pytest -m "time_seq" -n 1 --junitxml=report-2.xml

量化收益： | 指标 | 改造前（sleep/轮询） | 改造后（biz_date + 分组） | |------|---------------------|--------------------------| | 时间用例总耗时 | 3–4 小时 | < 30 秒（独立并行）+ < 15 秒（时序串行） | | 假失败率 | ~5%（轮询超时 + 时区漂移） | 0 | | 跨机器可复现 | 否（UTC 机器挂） | 是（biz_date 是纯日期） | | 并行安全 | 否（环境变量污染） | 是（请求级 header） |

避坑清单（可直接抄进团队 wiki）

• [ ] biz_date 走 header，不走环境变量（并行安全）
• [ ] 时间比较用 date，不用 datetime（消灭时区）
• [ ] 造数时 INSERT 就写对时间，禁止 UPDATE 时间戳
• [ ] 时序依赖用例标记 time_seq，单独串行跑
• [ ] CI 加 tz_guard，防止 UTC 机器混入
• [ ] 服务端 resolve_biz_date() 加白名单校验（只接受 YYYY-MM-DD，拒绝 datetime）
• [ ] 每周五跑一次"时间用例专项"（-m "time_independent or time_seq"），确认没有新增的隐式时间依赖

有任何一条卡住了欢迎追问。我手头有 pytest-xdist + biz_date 的完整 conftest 模板，需要可以贴出来。