🧪 测试差异

dzs/dzs-api

v1.0.70#3432

生成于 10-12 17:30 · 提交 cc8d2be · 发起人贾育锟

dzs-api v1.0.70 增量质检报告

项目：dzs/dzs-api
分支：v1.0.70
基准 commit（base）：73b0b3bdaa0d0139ef3b99791f9ae87471c8d799
目标 commit（head）：cc8d2bed2974dc41bf82fe43de2148f0dbae0ca3
质检对比口径：fixed = base 有 / head 无，added = head 有 / base 无（数据来自 codescan_issues_diff 真实结果，未编造）

一、变更概览（git diff）

本次增量仅 4 个文件、且生产逻辑改动很小，属于「一个功能 + 一次测试加固 + 文档」的版本：

文件	变更性质	内容摘要
`AGENTS.md`	文档	新增「连库用例与共享测试库」排查口径（2026-10-12）：共享测试库上价格计算器反复重写当天 `dzs_public_price` 行 → 连库用例随机假红；判据=单跑通过且失败点是数据快照过期；CI 无 PG/Redis 自动跳过；修法=紧邻重读 + 检测到并发改写就让位跳过，不得把断言放宽成永真
`src/services/ad_service.rs`	生产代码（新增）	新增 `admin_file_refs_in_text()`（markdown 文本级收集后台代理图片引用，原样 token + fileId）与 `rewrite_text_file_urls()`（纯函数，按映射整体替换 token）；另加 3 个单测
`src/services/article_service.rs`	生产代码（接入）	详情出口新增 `rewrite_content_file_urls()`，在 `shortcode::rewrite_placeholders` 之后对 `content_md` 做后台代理 URL → C 端文件代理地址重写
`src/services/data_service.rs`	测试加固	新增 `day_first_at()` helper；`anchor_is_time_precise_not_day_truncated` 改为断言前紧邻重读 + 并发改写让位跳过

功能主线：文章正文里的后台代理地址 /api/admin/files/{id}/content（后台域 + file:read 鉴权，C 端不可访问）重写为 /api/v1/file/{storage_path}（客户端拼自身域名）。实现与广告素材、文章封面图共用 admin_file_id_from_url / resolve_file_storage_paths / public_file_proxy_url，fail-soft（查不到 dzs_file / 软删 / DB 故障 → 原样透传），未命中不阻断。

二、修复的问题（base 有 / head 无，共 28 条）

重要结论：本版本无真实修复。 逐条比对 28 条「修复」与 33 条「新增」后确认：28 条全部是行号漂移——同一问题因新代码插入导致行号下移，在 head 以新行号重新出现（被同时记为“head 有/base 无”）。并非代码缺陷被消除。

原工具列出的 28 条「修复」及对应到 head 的漂移位置：

问题	base 行	漂移后 head 行	文件
嵌套深度过高 / 递归调用	420	481	ad_service.rs
重复代码块	550	611	ad_service.rs
函数过长	577	638	ad_service.rs
无安全注释的 unwrap ×6	959/963/969/975/983/984	1061/1065/1071/1077/1085/1086	ad_service.rs
参数过多	1489	1517	article_service.rs
嵌套深度过高	1563	1591	article_service.rs
函数过长 ×8	1822/2361/2945/3161/3388/3551/3874/4067	1850/2389/2973/3189/3416/3579/3902/4095	article_service.rs
行过长	2433	2461

即：这些复杂度/可维护性问题在 head 依然存在，只是位置变了。不要把本表当作“已修复”对外汇报。

三、新增的问题（head 有 / base 无，共 33 条）

3.1 真实新增（5 条，非行号漂移）

严重度	问题	位置	说明
Medium	高耦合	`src/services/ad_service.rs:396` `admin_file_refs_in_text`	直接依赖 15 个函数，超阈值 10。新函数的边界扫描把 `char_indices` / `matches!` / `find` / `admin_file_id_from_url` 等大量调用聚到一个函数里，建议把「左边界扩张 / 右边界校验」拆成独立小函数。
Medium	高耦合	`src/services/article_service.rs:1266` `rewrite_content_file_urls`	直接依赖 13 个函数，超阈值 10。为薄封装（collect→查库→建映射→替换），耦合主要来自 `HashMap`/`Diesel/SeaORM` 链路，可接受但建议后续统一抽到一个 `file_url_rewrite` 模块级 helper。
Medium	函数过长	`src/services/data_service.rs:2445` `anchor_is_time_precise_not_day_truncated`	测试函数从早前长度增长到 95 行（新增 `day_first_at` 重读 + 让位跳过逻辑）。测试代码，非生产缺陷。
Low

3.2 行号漂移重复项（28 条，与第二节一一对应）

ad_service.rs:481/611/638/1061/1065/1071/1077/1085/1086、article_service.rs:1517/1591/1850/2389/2973/3189/3416/3579/3902/4095、data_service.rs:2445(过长)/2461/2718/3066/3183/3456/3823/3934 —— 均为第二节「修复」列表的同一问题换了行号后重现。

新增问题净增量：生产代码 2 条（均为“高耦合”提示，非功能缺陷），其余为测试代码或误报/漂移。

四、代码审查发现的风险点（超出静态扫描器的判断）

4.1【Low，正确性】`rewrite_text_file_urls` 是子串整体替换，存在 token 重叠时替换错位

rewrite_text_file_urls（ad_service.rs）用 out.replace(token, rewritten) 逐个替换，而 HashMap 迭代顺序不确定：

当同一张图在正文中同时出现相对地址 /api/admin/files/24/content 与带 host 的绝对地址 https://host/api/admin/files/24/content 时，收集到两个 token，且相对 token 是绝对 token 的后缀。
若先替换相对 token，会把绝对 token 的后缀一并替换，结果剩下 https://host/api/v1/file/...（保留了后台 host 前缀，是错误 URL）；随后绝对 token 已不再匹配，无法补救。
新增单测 text_rewrite_replaces_only_mapped_tokens 用的是不同 fileId（24 / 99），未覆盖该重叠场景。

建议：按 token 长度降序替换，或改为边界感知（左/右邻字符非 URL 字符）替换并对已消费区间做标记。触发概率低（编辑器默认存相对地址），属防御性问题。

4.2【Low】正文重写只覆盖详情出口，口径已确认无遗漏

核对 src/handlers/article_handler.rs 与 article_service.rs：正文 markdown 仅从详情 ArticleDetailResp.content 出口返回；列表 ArticleListResp 只返回 cover_image（已由 rewrite_cover_images 重写），不返回正文。因此 rewrite_content_file_urls 覆盖详情出口即足够——未发现遗漏的正文出口。

4.3【Low】缓存窗口内的“软删文件仍可访问”属既有 fail-soft 语义

rewrite_content_file_urls 在详情构建（缓存 miss）时执行，替换后的 URL 随响应体进入 Redis 缓存。若文件随后被软删，缓存 TTL 内 URL 仍指向 /api/v1/file/{storage_path}。此为既有封面图/广告一致的 fail-soft 语义，非本版本引入，记录备查。

4.4【Info】`admin_file_refs_in_text` 边界与性能

左边界向“URL 允许字符”扩张、右边界取 /content 且校验其后不得再接 URL 路径字符，逻辑与 admin_file_id_from_url 的严格校验配合得当，未发现越界/panic 风险（&text[end..] 中 end ≤ text.len()，find 无结果时安全前进，循环必然收敛）。
复杂度 O(n·k)（n=正文长度，k=标记数），正文体量下可接受；对超大正文无显式上限保护，属可忽略项。

4.5【Info】`data_service` 测试加固的写法提醒

anchor_is_time_precise_not_day_truncated 在检测到并发改写时用 return（而非 continue）直接结束整个用例。符合 AGENTS.md「数据无关纪律：不得因并发写而红」，方向正确；但 return 会连同剩余品类一起跳过，若首个品类即触发跳过，用例会零断言通过。建议后续补一条「至少校验过 N 个品类」的兜底断言或改为 continue，以免长期失真（不要把断言放宽成永真，这与 AGENTS.md 一致）。

五、结论与建议

功能：正文后台代理图片地址重写链路（admin_file_refs_in_text → resolve_file_storage_paths → public_file_proxy_url → rewrite_text_file_urls）设计自洽，与封面图/广告共用实现，fail-soft 到位；出口覆盖完整，无阻断性缺陷。
本版本“修复 28 条”为行号漂移，无真实修复；对外汇报时须避免把它当成收益。
新增问题净增量很小：生产代码仅 2 条「高耦合」提示（新函数引入，非功能问题）；其余为测试代码或误报/漂移。
建议优先项：
- （可选）修复/防御 rewrite_text_file_urls 的 token 重叠子串替换问题（4.1），并补一条“相对+绝对同文件混用”的单测；
- data_service 让位跳过改为 continue 或增加“已校验品类数”断言（4.5）；
- admin_file_refs_in_text 可拆分以降低耦合告警（3.1）。