dev

docs/01_domainCheck_验收清单.md

@@ -0,0 +1,267 @@
+# domainCheck 验收清单
+
+基于 [需求文档内容_utf8.txt](/d:/www/py/domainCheck/需求文档内容_utf8.txt:1) 与当前项目代码、环境联调结果整理。
+
+判定说明：
+- `可验收`：已有实现，能进入验收或复测阶段。
+- `部分可验收/需优化`：已有基础实现，但与需求有差距，不能算完全交付。
+- `未完成/不通过`：关键功能缺失、逻辑不闭环或与需求明显不符。
+
+## 一、总体结论
+
+- `可验收`：桌面端主程序已在本地 Windows 跑起，远程 PostgreSQL、Redis 已连通，基础 UI 已打开。
+- `部分可验收/需优化`：域名导入、聚名采集、时光机基础检测、筛选页、系统设置页、数据库初始化。
+- `未完成/不通过`：完整检测闭环、部分来源采集、TXT 导出、状态码一致性、数据库任务落库稳定性、筛选条件完整性。
+
+## 二、可验收项
+
+### 1. Windows 本地运行环境
+
+- `状态`：可验收
+- `结果`：项目已在 Windows + PySide6 环境下启动成功，主窗口标题为“域名工具”。
+- `说明`：不是必须 Linux，当前更像是 Windows 桌面工具 + 远程 PostgreSQL/Redis 的架构。
+
+### 2. 基础数据库初始化
+
+- `状态`：可验收
+- `结果`：`domains`、`detect_tasks`、`domain_blacklist`、`sensitive_words`、`domain_detections` 表已成功初始化。
+- `说明`：数据库能连通，初始化脚本已跑通。
+
+### 3. 基础界面框架
+
+- `状态`：可验收
+- `结果`：主界面标签页已创建。
+- `已见模块`：
+- 聚名爬取
+- 域名筛选
+- 域名导入
+- 敏感词配置
+- 系统设置
+
+### 4. 手工输入/TXT 导入域名
+
+- `状态`：可验收
+- `结果`：已有文本框导入、TXT 文件导入、进度显示、去重入库流程。
+- `说明`：符合“手动批量添加域名、窗口输入或导入 txt”的基础要求。
+
+### 5. 聚名一口价/过期删除采集界面
+
+- `状态`：可验收
+- `结果`：已有聚名采集页面，可选一口价或删除列表，并支持自动入库。
+- `说明`：基础页面和采集流程已存在，适合做功能复测。
+
+### 6. 敏感词录入窗口
+
+- `状态`：可验收
+- `结果`：已有敏感词配置界面与数据库表。
+- `说明`：界面层面满足“敏感词录入窗口”。
+
+## 三、部分可验收/需优化
+
+### 1. `.com/.net` 域名标准化与过滤
+
+- `状态`：部分可验收/需优化
+- `已实现`：
+- 小写化
+- 去空格
+- 去协议
+- 去路径/参数
+- 只保留主域
+- 过滤 `.com/.net`
+- `需优化`：
+- 当前实现适合常规导入，但离“全网增量大库”还差批次管理、来源追踪、海量导入策略。
+
+### 2. 时光机检测
+
+- `状态`：部分可验收/需优化
+- `已实现`：
+- 使用 Wayback CDX API
+- 获取快照年份
+- 拉取快照内容做敏感词匹配
+- 有外链数量统计函数
+- `需优化`：
+- 现在更像“基础版”
+- 只抓最近快照，不是按年份抽样
+- 敏感词命中规则不完整
+- 友链数没有完整接入自动筛选闭环
+
+### 3. 平台检测器插件化结构
+
+- `状态`：部分可验收/需优化
+- `已实现`：
+- RDAP
+- Wayback
+- 百度
+- 360
+- Google
+- Chinaz
+- 爱站
+- 桔子 SEO
+- 聚查
+- `需优化`：
+- 结构上是插件化了，但规则实现深度、数据落库字段、停机规则还不完整。
+
+### 4. 运营筛选页面
+
+- `状态`：部分可验收/需优化
+- `已实现`：
+- 注册状态筛选
+- 使用状态筛选
+- 检测状态筛选
+- 复核状态筛选
+- 备案年份
+- 快照年份
+- 网址搜索
+- 域名搜索
+- 批量更新部分字段
+- `需优化`：
+- 有些筛选项只是界面有，查询 SQL 没完整接上。
+- 状态枚举和需求定义不完全一致，可能导致筛选结果失真。
+
+### 5. Redis 集成
+
+- `状态`：部分可验收/需优化
+- `已实现`：
+- Redis 连接
+- 配置同步
+- 普通缓存
+- `需优化`：
+- Redis Bloom 模块未安装，布隆过滤器不可用，当前已退回普通缓存。
+
+### 6. 检测端多开思路
+
+- `状态`：部分可验收/需优化
+- `已实现`：
+- 存在独立 `detect_worker.py`
+- 有单独界面与线程逻辑
+- `需优化`：
+- 稳定性、任务调度与数据库连接模型仍需重构后再做压力验收。
+
+## 四、未完成/不通过项
+
+### 1. 检测任务落库与完整闭环
+
+- `状态`：未完成/不通过
+- `问题`：
+- 检测任务创建、完成任务清理、检测结果写入这几处数据库代码混用了未初始化的 `self.conn/self.cur`
+- 导致“入库后自动建任务、检测后写结果”的主流程不稳定
+- `影响`：这是核心闭环问题，必须整改后再验收。
+
+### 2. 状态码体系不统一
+
+- `状态`：未完成/不通过
+- `问题`：
+- 注册状态
+- 检测状态
+- UI 展示映射
+- 工具函数映射
+- 检测器返回值
+- 上述几套定义互相不一致
+- `影响`：筛选、导出、拉黑、运营判断都可能错位。
+
+### 3. 多来源采集未真正完成
+
+- `状态`：未完成/不通过
+- `未完成项`：
+- 搜索引擎采集
+- 企业目录采集
+- Zone File 采集
+- 第三方接口/数据包采集
+- `说明`：代码里这些入口还是占位实现。
+
+### 4. 导出 TXT
+
+- `状态`：未完成/不通过
+- `需求`：导出 `txt`，一行一个域名
+- `现状`：当前只支持 Excel/CSV 导出
+- `影响`：与需求明确不符
+
+### 5. “友链数量 > 10”筛选未真正生效
+
+- `状态`：未完成/不通过
+- `问题`：界面有选项，但查询条件没有完整落到数据库筛选逻辑上。
+
+### 6. 停止规则未完整落地
+
+- `状态`：未完成/不通过
+- `需求`：
+- 黑名单命中后停止后续检测
+- 已使用/已卖出/已预定不进运营池
+- 非可注册且非一口价不进可注册池
+- `现状`：只实现了部分拉黑中止，完整运营池/可注册池规则没有闭环。
+
+### 7. 需求中的人工筛选脚本化规则未完整落地
+
+- `状态`：未完成/不通过
+- `未完整实现的规则示例`：
+- 站长之家分类敏感规则
+- 爱站风险词规则
+- 百度/360 子域名规则
+- 百度安全中心危险判定
+- 聚查备案年份、单位性质、首页一致性规则
+- 聚查拦截检测规则
+- 桔子 SEO 历史中文/敏感词/外链锚文本规则
+
+### 8. 敏感词配置未真正全链路生效
+
+- `状态`：未完成/不通过
+- `问题`：虽然有敏感词配置窗口，但部分主检测逻辑仍使用代码里写死的词表。
+
+### 9. 亿级数据量设计能力不能验收
+
+- `状态`：未完成/不通过
+- `问题`：
+- 当前是桌面工具式实现
+- 数据库表结构和索引策略不足以证明“支持亿级”
+- 连接池、批量任务、并发模型仍偏脆弱
+
+## 五、建议先验收通过的范围
+
+如果要分阶段验收，当前只建议先验这部分：
+
+- 本地 Windows 启动成功
+- 远程 PostgreSQL/Redis 连通
+- 数据库初始化成功
+- 主界面与各标签页打开成功
+- 手工/TXT 导入可用
+- 聚名页面可打开并具备基础采集入口
+- 敏感词页面可打开
+- 基础时光机检测模块存在
+
+## 六、必须整改后再验收的范围
+
+- 检测任务自动创建与检测结果落库
+- 状态码统一
+- 检测闭环完整性
+- TXT 导出
+- 多来源采集补齐
+- 关键人工规则脚本化
+- 敏感词全链路配置化
+- 运营筛选条件完整生效
+
+## 七、建议优化项
+
+- 数据库连接池继续做成环境配置，区分测试/生产
+- Redis Bloom 如有需要可安装 RedisBloom 模块
+- 配置加载时避免界面初始化阶段频繁重复写 Redis
+- 敏感词、风险词、平台规则拆成可维护配置
+- 导出支持 TXT/CSV/Excel 三种
+- 数据库增加更清晰的来源批次、任务批次、失败重试日志
+- 清理明文账号密码存储问题
+
+## 八、建议的复测顺序
+
+1. 域名导入
+2. 聚名采集入库
+3. 注册状态检测
+4. 时光机快照年份与敏感词检测
+5. 平台检测结果写库
+6. 筛选条件查询
+7. 批量更新使用状态/人工复核状态
+8. TXT 导出
+
+## 九、当前验收结论
+
+- `阶段性可验收`：环境、界面、基础导入、基础采集、基础数据库
+- `不能整体验收通过`：核心业务闭环还不完整，尤其是任务写库、状态码一致性、TXT 导出和人工规则脚本化
+

docs/02_domainCheck_优化清单_待审核.md

@@ -0,0 +1,426 @@
+# domainCheck 优化清单（待审核）
+
+这份清单用于你先做取舍，不是默认全部都要做。
+
+## 当前实施状态
+
+- `统计时间`：2026-04-15
+- `说明`：以下状态基于当前代码、启动验证、数据库结构补齐和本地联调结果更新。
+- `状态口径`：
+- `已完成`：代码已落地，基础验证已通过
+- `已完成，待复测`：代码已落地，但还需要你结合真实业务样本再跑一轮人工回归
+- `继续优化`：已做一部分，但还没完全做到最终验收态
+- `暂不做`：按你的审核备注，本轮不纳入
+
+## 最近回归
+
+- `回归时间`：2026-04-16
+- `回归方式`：脚本化构造测试域名，直接验证导入、筛选、导出、批量更新关键链路
+- `已通过项`：
+- 备案筛选能区分“有备案记录 / 没有备案记录”
+- `友链 > 10` 筛选可真实命中
+- 检测时间字段可正常读出
+- TXT 导出可一行一个域名
+- 分页导出底层查询链路可正常返回分页结果
+- 批量更新选中域名在真实 Unicode 参数下可正常更新 `review_status / has_beian / detect_time / website_url / backlink_count / domain_detections`
+- `仍需人工复测项`：
+- GUI 实际点击流程的导入与导出交互
+- 检测端联动聚查、桔子补查
+- 时光机全快照倒序扫描、标题判词、命中即停的真实网络耗时与命中效果
+
+## 最新检测联调
+
+- `联调时间`：2026-04-16
+- `联调范围`：导入建任务、补查取数、单域名真实检测执行、单域名命中黑名单后中止
+- `已验证结果`：
+- 导入 TXT 域名后可自动创建 `detect_tasks`
+- 聚查、桔子二次补查取数正常，且已拉黑域名不会进入补查队列
+- 单域名走“正常完成”路径时：
+- `detect_status` 会更新为检测完成
+- `detect_time` 会写入
+- `review_status` 会更新为待人工复核
+- 当满足条件时 `expire_date` 会被清空
+- 单域名走“命中中止”路径时：
+- `detect_status` 会更新为黑名单
+- 黑名单原因会写入 `domain_blacklist`
+- 时光机产生的 `snapshot_years` 可正常落库；当前按审核口径改为 title-only 检测后，`backlink_count / backlink_count_gt_10` 默认不再作为时光机产出字段
+- 命中后不会写入 `detect_time`
+- `当前风险`：
+- Wayback 对历史快照极多的域名，主要瓶颈已收敛到 CDX 时间戳列表获取；首次扫描超大域名仍可能受网络波动影响，但已补充 Redis 时间戳缓存，二次检测会明显更快
+
+分级说明：
+- `P0 必须做`：不做会影响验收、主流程闭环或结果正确性。
+- `P1 建议做`：不一定阻塞首轮验收，但会明显影响实用性、稳定性或后续维护。
+- `P2 可选做`：属于增强项、体验项、扩展项，可按预算和阶段决定。
+
+---
+
+## 一、P0 必须做
+
+### 1. 检测任务落库闭环修复
+
+- `当前状态`：`已完成，待复测`
+
+- `目的`：保证域名入库后，待检测任务能正确创建、执行、回写结果。
+- `当前问题`：数据库代码里任务创建、任务清理、结果写入存在连接对象使用不一致的问题，主流程不稳定。
+- `不做影响`：检测流程可能根本不闭环，属于核心不通过项。
+- `建议结论`：`必须做`
+
+### 2. 检测结果写库修复
+
+- `当前状态`：`已完成，待复测`
+
+- `目的`：让百度/360/Google/时光机/聚查等结果能稳定入库。
+- `当前问题`：部分结果写入逻辑依赖不稳定的数据库连接对象。
+- `不做影响`：界面查得到的结果不可信，后续筛选和导出都会失真。
+- `建议结论`：`必须做`
+
+### 3. 状态码统一
+
+- `当前状态`：`已完成`
+
+- `范围`：
+- 注册状态
+- 检测状态
+- 使用状态
+- 复核状态
+- UI 显示映射
+- 检测器返回值
+- `当前问题`：需求文档、数据库、检测器、筛选页的状态定义不一致。
+- `不做影响`：筛选结果错误，黑名单/正常/可注册等状态可能串位。
+- `建议结论`：`必须做`
+
+### 4. TXT 导出补齐
+
+- `当前状态`：`已完成`
+
+- `目的`：满足需求中的“导出 txt，一行一个域名”。
+- `当前问题`：当前只支持 Excel/CSV。
+- `不做影响`：需求明确不符合，验收容易直接打回。
+- `建议结论`：`必须做`
+审核：这个其实不影响，或者你可以多加一个导出为txt 选项
+### 5. 筛选条件真正落库生效
+
+- `当前状态`：`已完成，待复测`
+
+- `重点项`：
+- 快照年份
+- 备案年份
+- 首页网址
+- 友链数是否大于 10
+- 是否有备案历史
+- 部分状态筛选
+- `当前问题`：有些条件只有界面，没有真正进入 SQL 查询。
+- `不做影响`：运营筛选失真，界面“看起来有”但实际不可用。
+- `建议结论`：`必须做`
+
+### 6. 敏感词全链路配置化
+
+- `当前状态`：`已完成，待复测`
+
+- `目的`：让敏感词配置窗口真正决定检测规则。
+- `当前问题`：主流程里仍有写死词表。
+- `不做影响`：虽然有敏感词页面，但配置不能完全生效，需求不满足。
+- `建议结论`：`必须做`
+审核：必须要读取软件出口提交的 敏感词
+
+### 7. 停止规则补齐
+
+- `当前状态`：`继续优化`
+
+- `需求核心`：
+- 黑名单命中后停止后续检测
+- 已使用/已卖出/已预定不进运营池
+- 非可注册且非一口价不进入可注册池
+- `当前问题`：只实现了部分拉黑中止，完整规则未闭环。
+- `不做影响`：浪费检测资源，筛选池不准确。
+- `建议结论`：`必须做`
+
+### ++ 8. 聚查、桔子增加独立检测状态
+
+- `当前状态`：`已完成，待复测`
+
+- `优先级`：`P0 必须做`
+- `目的`：为聚查、桔子增加“未检测 / 已检测”状态，用于支持增量补查。
+- `人工验收反馈`：
+- 第一次检测时如果未勾选聚查、桔子，则只按当前检测选项执行
+- 第二次检测时如果勾选了聚查、桔子，则数据库中尚未检测过聚查、桔子的域名需要补查一次
+- 若选中的流程全部执行完且未命中黑名单，则总状态应更新为“检测完成”
+- `不做影响`：二次检测无法按需补查，检测状态判断不准确。
+
+### ++ 9. 检测选项配置与实际检测流程需一致
+
+- `当前状态`：`已完成，待复测`
+
+- `优先级`：`P0 必须做`
+- `人工验收反馈`：
+- 目前仅希望配置以下检测项：
+- 检查注册
+- 站长之家查询
+- 爱站网查询
+- 百度 site 查询
+- 360 的 site 查询
+- 域名检测端运行十多个小时仍在跑，用户无法理解实际执行范围
+- `优化要求`：
+- 系统设置中的检测选项必须与实际检测流程一致
+- 未勾选的检测项不得执行
+- 需要有明确的执行状态反馈
+
+### ++ 10. 域名筛选结果需显示检测时间
+
+- `当前状态`：`已完成`
+
+- `优先级`：`P0 必须做`
+- `人工验收反馈`：
+- 条件“注册状态=可注册、使用状态=未使用、检测状态=检测完成”查询后，没有显示检测时间
+- 用户定义：检测时间 = 检测完成时间
+- `不做影响`：运营无法判断结果数据的新旧。
+
+### ++ 11. 域名筛选导出需支持导出多页或全部
+
+- `当前状态`：`已完成`
+
+- `优先级`：`P0 必须做`
+- `人工验收反馈`：
+- 当前默认一页 100 条，需增加“导出几页”或“导出全部”的功能
+- `不做影响`：运营无法批量导出完整结果。
+
+### ++ 12. “是否有备案”筛选需真实生效
+
+- `当前状态`：`已完成，待复测`
+
+- `优先级`：`P0 必须做`
+- `人工验收反馈`：
+- 域名筛选中是否勾选“是否有备案”，出现的域名结果都一样
+- `不做影响`：筛选结果不可信，需求不满足。
+
+### ++ 13. 批量更新选中域名功能需修复
+
+- `当前状态`：`已完成，待复测`
+
+- `优先级`：`P0 必须做`
+- `人工验收反馈`：
+- 已选中域名后执行“批量更新选中域名”，提示“成功更新0个域名的信息”
+- `不做影响`：运营批量操作不可用。
+
+### ++ 14. 检测选项配置中需补充时光机检测开关
+
+- `当前状态`：`已完成`
+
+- `优先级`：`P0 必须做`
+- `人工验收反馈`：
+- 系统设置中的检测选项没有“时光机检测”，但检测流程第二步就是时光机
+- `不做影响`：配置项与实际业务流程不一致，无法控制时光机是否执行。
+
+---
+
+## 二、P1 建议做
+
+### 8. 时光机检测按审核口径升级为“全快照倒序扫描标题，命中即停”
+
+- `当前状态`：`已完成，待复测`
+
+- `当前状态`：已使用 Wayback/CDX API 获取全量快照时间戳。
+- `当前实现`：
+- 按时间倒序扫描全部快照
+- 仅抓取每个快照的 `title`，不再抓取正文
+- 按 `title` 去重
+- 先快速检查最新快照，命中后不再继续拉全量快照列表
+- 同时使用 CDX 返回的 `digest` 先做一轮内容级去重，减少无效 title 请求
+- 任一快照标题命中敏感词后立即停止后续扫描
+- 已增加 Redis 持久缓存：标题缓存 + 时间戳列表缓存
+- `剩余风险`：首次扫描历史快照极多的老域名时，CDX 时间戳列表获取仍可能偏慢。
+- `建议结论`：`已完成，继续复测性能`
+- 审核备注：必须全部快照检查，不能随机；只要一个快照标题命中敏感词，则判定黑名单并停止后续扫描
+
+### 9. 友链数量自动落库和自动筛选联动
+
+- `当前状态`：`继续优化`
+
+- `当前状态`：筛选链路已支持 `友链 > 10`，但按当前审核口径改为 title-only 时光机检测后，不再从时光机正文自动计算友链数量。
+- `建议价值`：如后续仍需自动产出友链数量，需要单独补一条正文抓取或其他来源统计链路。
+- `是否阻塞首轮验收`：`看是否把友链自动检测作为必验项`
+- `建议结论`：`按你的复测结果决定是否继续做`
+
+### 10. 人工筛选规则脚本化补齐
+
+- `当前状态`：`继续优化`
+
+- `范围`：
+- 站长之家标题/分类规则
+- 爱站风险词规则
+- 百度/360 子域名规则
+- 聚查备案年份/单位性质/首页一致性/拦截规则
+- 桔子 SEO 历史词、中文标题、外链锚文本规则
+- `当前状态`：有平台检测器，但规则覆盖不完整。
+- `建议价值`：这是把“人工流程”转成“机器流程”的关键。
+- `是否阻塞首轮验收`：看甲方是否按文档逐条验。
+- `建议结论`：`建议做`
+
+### 11. 检测端稳定性优化
+
+- `当前状态`：`已完成一轮基础优化，待长时复测`
+
+- `内容`：
+- 连接池配置化
+- 并发线程数控制
+- 失败重试逻辑梳理
+- 任务队列模型修正
+- `当前状态`：已把默认连接池降小，但整体并发/连接模型仍偏脆弱。
+- `建议价值`：适合进入持续检测前做。
+- `是否阻塞首轮验收`：`通常不阻塞`
+- `建议结论`：`建议做`
+
+### 12. 配置写入频率优化
+
+- `当前状态`：`已完成`
+
+- `当前问题`：系统设置页初始化过程中会多次重复写本地文件/Redis。
+- `建议价值`：降低噪音日志和无谓写入。
+- `是否阻塞首轮验收`：`不阻塞`
+- `建议结论`：`建议做`
+
+### 13. 明文密码存储整改
+
+- `当前状态`：`已完成`
+
+- `当前问题`：本地文件中存在明文账号密码存储。
+- `建议价值`：安全性和交付规范更好。
+- `是否阻塞首轮验收`：多数情况下不阻塞功能验收，但属于明显风险。
+- `建议结论`：`建议做`
+
+---
+
+## 三、P2 可选做  
+
+### 14. 搜索引擎采集补齐
+
+- `当前状态`：`暂不做`
+
+- `内容`：根据关键词从搜索引擎持续采集域名入库。
+- `当前状态`：有占位入口，未真正实现。
+- `价值`：有利于做“全网增量建设”。
+- `是否必须`：如果当前先验一口价+删除列表+手工导入，不一定必须。
+- `建议结论`：`可选做`
+审核：这个可以暂时不做
+
+### 15. 企业目录采集补齐
+
+- `当前状态`：`暂不做`
+
+- `内容`：抓取企业目录网站的公司域名。
+- `当前状态`：有占位入口，未实现。
+- `价值`：增强全网增量来源。
+- `是否必须`：首轮不一定必须。
+- `建议结论`：`可选做`
+审核：这个可以暂时不做
+
+### 16. Zone File 采集补齐
+
+- `当前状态`：`暂不做`
+
+- `当前状态`：有占位入口，未实现。
+- `价值`：适合后期扩充大库。
+- `是否必须`：当前阶段通常不是必须。
+- `建议结论`：`可选做`
+审核：这个可以暂时不做
+
+### 17. 第三方 API/数据包接入
+
+- `当前状态`：`继续优化`
+
+- `当前状态`：需求有提及，但项目未形成稳定接入方案。
+- `价值`：提升数据来源多样性。
+- `是否必须`：不是首轮必做。
+- `建议结论`：`可选做`
+审核：这个可以暂时不做
+
+### 18. Redis Bloom 模块支持
+
+- `当前状态`：`继续优化`
+
+- `当前状态`：Redis 已通，但未安装 RedisBloom，当前已退回普通缓存。
+- `价值`：对海量去重更有帮助。
+- `是否必须`：首轮本地联调不必须。
+- `建议结论`：`可选做`
+
+### 19. 亿级数据量数据库专项优化
+
+- `当前状态`：`暂不做`
+
+- `内容`：
+- 更细索引策略
+- 分区或分表设计
+- 任务批次管理
+- 大批量导入方案
+- `价值`：面向大规模生产阶段。
+- `是否必须`：当前桌面版联调阶段不是必须。
+- `建议结论`：`可选做`
+审核：这个可以暂时不做
+
+### 20. UI 体验类优化
+
+- `当前状态`：`继续优化`
+
+- `内容`：
+- 更清晰的状态说明
+- 批量操作反馈优化
+- 查询条件联动提示
+- 导出成功/失败结果更明确
+- `是否必须`：非核心
+- `建议结论`：`可选做`
+
+---
+
+## 四、建议你审核时优先决定的项
+
+这几项建议你先拍板，因为会直接决定我后面怎么开工：
+
+- 是否把 `TXT 导出` 作为首轮必须项
+- 是否把 `时光机按年份抽样` 作为首轮必须项
+- 是否把 `人工筛选规则脚本化` 作为首轮必须项
+- 是否把 `搜索引擎/企业目录/Zone file 采集` 放到二期
+- 是否需要同步处理 `明文密码存储`
+
+---
+
+## 五、我建议的默认实施范围
+
+如果你不想一次做太大，我建议默认先做下面这些：
+
+### 默认先做
+
+- 检测任务落库闭环修复
+- 检测结果写库修复
+- 状态码统一
+- TXT 导出
+- 筛选条件真正生效
+- 敏感词全链路配置化
+- 停止规则补齐
+
+### 默认后做
+
+- 时光机按年份抽样
+- 人工筛选规则脚本化补齐
+- 安全整改
+- 稳定性与架构优化
+
+### 默认不纳入首轮
+
+- 搜索引擎采集
+- 企业目录采集
+- Zone file 采集
+- 第三方 API/数据包扩展
+- Redis Bloom
+- 亿级数据量专项优化
+
+
+审核总结：
+## 一、P0 必须做   必须做
+## 二、P1 建议做   必须做
+## 三、P2 可选做   根据我审核备注来做，没审核的做
+
+当前执行结论：
+- `P0`：已基本落地，建议你按“导入 -> 检测 -> 筛选 -> 导出 -> 批量更新”做一轮人工复测
+- `P1`：已完成大部分主干优化，剩余重点在“停止规则细化”和“人工筛选规则脚本化”
+- `P2`：已按你的备注暂缓未审核项，不影响当前主线联调

docs/03_domainCheck_整改清单_外包版.md

@@ -0,0 +1,427 @@
+# domainCheck 项目整改清单（外包沟通版）
+
+本文档用于当前版本项目的整改确认与后续复测对齐。  
+依据为现有交付代码、运行联调结果及 [需求文档内容_utf8.txt](/d:/www/py/domainCheck/需求文档内容_utf8.txt:1)。
+
+请外包方根据本清单逐项确认：
+- 是否已完成
+- 如未完成，预计整改方案与时间
+- 如有与需求理解不一致之处，请逐项书面说明
+
+## 当前联调状态
+
+- `更新时间`：2026-04-15
+- `说明`：以下状态由当前代码联调结果同步，便于外包方按项书面回复。
+- `状态口径`：
+- `已整改`：代码已落地，待外包方和甲方复测确认
+- `整改中`：已有部分优化，但仍需继续补齐
+- `暂缓`：按当前阶段安排，不纳入首轮阻塞项
+
+## 最近复测结果
+
+- `复测时间`：2026-04-16
+- `复测范围`：导入测试数据、筛选查询、TXT/分页导出、批量更新
+- `复测结论`：
+- 备案筛选、友链大于 10 筛选、检测时间展示、TXT 导出、分页导出底层链路均已通过脚本化复测
+- 批量更新选中域名在实际代码链路下已验证可正常更新数据库
+- 当前仍建议外包方配合做一轮 GUI 人工复测与检测端全流程复测，再关闭整改项
+
+## 最新检测联调结果
+
+- `联调时间`：2026-04-16
+- `联调范围`：导入建任务、聚查/桔子补查取数、单域名检测完成路径、单域名命中黑名单路径
+- `联调结论`：
+- TXT 导入后可自动创建待检测任务
+- 聚查、桔子补查逻辑已可按状态取数，且黑名单域名不会再次进入补查
+- 单域名检测完成后，`detect_status / detect_time / review_status / expire_date` 联动已验证正常
+- 单域名命中风险后，`detect_status / domain_blacklist / 时光机附加字段` 联动已验证正常
+- 当前 Wayback 已按最新验收口径调整为“全快照倒序扫描标题、命中即停、标题去重、结果缓存”
+- 当前保留风险主要为超大域名首次获取 CDX 时间戳列表时的耗时问题；已补充 Redis 时间戳缓存，建议外包方继续优化首次全量列表获取策略
+
+---
+
+## 一、整改结论
+
+当前版本可以完成基础启动、基础界面展示、远程数据库连接与部分导入/采集功能，但**暂不具备整体验收通过条件**。  
+主要原因是核心检测闭环、状态定义一致性、部分导出与筛选逻辑、以及多项需求规则尚未完整落地。
+
+为避免后续复测口径不一致，现将整改事项分为以下三类：
+- `一类问题`：必须整改，整改完成后方可进入整体验收
+- `二类问题`：建议整改，影响可用性、稳定性或需求完整度
+- `三类问题`：可按阶段排期，属于增强项或扩展项
+
+---
+
+## 二、一类问题（必须整改）
+
+### 1. 检测任务创建、执行、结果回写需形成完整闭环
+
+- `当前状态`：`已整改`
+
+- `问题说明`：当前版本中，域名入库后“创建待检测任务”、检测完成后“回写检测结果”的流程不稳定，部分数据库写入逻辑存在连接对象使用不一致的问题。
+- `需求依据`：需求文档明确要求入库后创建待检测任务，并通过流水线方式持续检测与更新数据库状态。
+- `整改要求`：
+- 保证入库后可稳定创建待检测任务
+- 保证检测完成后可稳定写入检测结果
+- 保证失败任务、重试任务、已完成任务状态可追踪
+- `验收标准`：
+- 随机导入一批域名后，可在数据库中看到对应任务
+- 执行检测后，数据库状态与检测结果表有完整回写
+
+### 2. 状态码定义必须统一
+
+- `当前状态`：`已整改`
+
+- `问题说明`：当前项目中注册状态、检测状态等枚举值在数据库、检测器、工具函数、界面显示之间存在不一致。
+- `需求依据`：需求文档已给出明确状态定义。
+- `整改要求`：
+- 统一注册状态枚举
+- 统一检测状态枚举
+- 统一使用状态、人工复核状态枚举
+- 确保数据库值、代码逻辑、界面显示、导出结果一致
+- `验收标准`：
+- 任取一个域名，其数据库状态、界面显示、导出内容含义一致
+
+### 3. 导出功能需补齐 TXT 格式
+
+- `当前状态`：`已整改`
+
+- `问题说明`：需求要求“导出 TXT，一行一个域名”，当前版本仅支持 Excel/CSV。
+- `需求依据`：运营导出明确要求 TXT 格式。
+- `整改要求`：
+- 增加 TXT 导出
+- 每行一个域名
+- 导出内容与当前筛选结果一致
+- `验收标准`：
+- 在筛选结果页导出 TXT，文件内容符合“一行一个域名”
+
+### 4. 筛选条件必须真实生效，不能仅停留在界面层
+
+- `当前状态`：`已整改`
+
+- `问题说明`：当前部分筛选项虽已在界面存在，但未完整进入查询逻辑，导致界面与结果不一致。
+- `重点项`：
+- 注册状态
+- 检测状态
+- 使用状态
+- 备案年份
+- 快照年份
+- 是否有备案历史
+- 友链数量是否大于 10
+- 首页网址筛选
+- `整改要求`：
+- 所有界面筛选条件必须真正作用于数据库查询
+- 查询结果必须与筛选条件一致
+- `验收标准`：
+- 通过构造测试数据，验证各筛选项结果准确
+
+### 5. 敏感词配置必须全链路生效
+
+- `当前状态`：`已整改`
+
+- `问题说明`：当前虽然存在敏感词配置页面，但部分检测逻辑仍使用写死词表。
+- `需求依据`：需求明确要求“敏感词、风险词必须可配置”。
+- `整改要求`：
+- 检测流程统一从配置或数据库读取敏感词
+- 不再保留独立的写死敏感词规则作为主判定来源
+- `验收标准`：
+- 新增/删除敏感词后，检测结果可随配置变化
+
+### 6. 停止规则需完整落实
+
+- `当前状态`：`整改中`
+
+- `问题说明`：需求文档中对停止检测、进入候选池、排除运营池等有明确规则，当前只实现了部分中止逻辑。
+- `整改要求`：
+- 黑名单命中后停止后续检测
+- 已使用/已卖出/已预定域名不进入运营候选池
+- 非可注册且非一口价域名不进入“可注册域名池”
+- `验收标准`：
+- 按规则构造测试样本，流程结果符合需求定义
+
+### 7. 核心检测流程需与需求步骤一致
+
+- `当前状态`：`整改中`
+
+- `问题说明`：当前版本已有基础检测器，但与需求中的完整筛选链路仍有差距。
+- `需求链路`：
+- 注册状态检测
+- 黑名单缓存检查
+- 时光机基础筛选
+- 各平台深度检测
+- 备案检测
+- 更新数据库
+- 运营筛选导出
+- `整改要求`：
+- 明确各步骤执行顺序
+- 明确每一步的中止条件
+- 明确每一步的结果回写字段
+- `验收标准`：
+- 随机抽取样本域名，能完整追踪检测执行链路
+
+### ++ 8. 聚查、桔子需增加独立检测状态并支持增量补查
+
+- `当前状态`：`已整改`
+
+- `问题说明`：人工验收反馈中提出，聚查、桔子当前缺少独立检测状态，无法区分“未检测”和“已检测”，导致二次检测场景下无法按需补查。
+- `业务要求`：
+- 第一次检测时，如未勾选聚查、桔子，则仅按当次检测选项执行
+- 第二次检测时，如新增勾选聚查、桔子，则数据库中尚未检测过聚查、桔子的域名需补查一次
+- 当本次选中的流程全部执行完且未命中黑名单时，总检测状态应更新为“检测完成”
+- `整改要求`：
+- 为聚查、桔子增加独立检测状态字段或等效机制
+- 支持按子项状态触发增量补查
+- 明确总检测状态与子项检测状态的联动关系
+- `验收标准`：
+- 构造“第一次未勾选、第二次勾选”的测试场景，验证聚查、桔子可正确补查
+
+### ++ 9. 检测选项配置需与实际执行流程保持一致
+
+- `当前状态`：`已整改`
+
+- `问题说明`：人工验收反馈指出，系统设置中仅配置了少量检测项，但检测端运行耗时异常，无法明确系统实际执行了哪些检测流程。
+- `人工反馈重点`：
+- 当前希望可配置的检测项包括：
+- 检查注册
+- 站长之家查询
+- 爱站网查询
+- 百度 site 查询
+- 360 site 查询
+- `整改要求`：
+- 系统设置中的检测选项必须与实际执行逻辑严格一致
+- 未勾选的检测项不得执行
+- 检测端应能清晰反映当前执行项
+- `验收标准`：
+- 在仅勾选部分检测项时，日志与结果仅体现对应检测流程
+
+### ++ 10. 域名筛选结果中需显示检测时间
+
+- `当前状态`：`已整改`
+
+- `问题说明`：人工验收反馈中，在“注册状态=可注册、使用状态=未使用、检测状态=检测完成”条件下查询后，结果列表未显示检测时间。
+- `业务口径`：检测时间 = 检测完成时间。
+- `整改要求`：
+- 检测完成后必须回写检测完成时间
+- 筛选结果页需显示该时间
+- `验收标准`：
+- 随机选取已检测完成域名，列表中可看到检测完成时间
+
+### ++ 11. 域名筛选导出需支持“导出多页”或“导出全部”
+
+- `当前状态`：`已整改`
+
+- `问题说明`：当前导出范围仅限当前页，不满足实际运营导出需求。
+- `整改要求`：
+- 在导出时增加导出范围选择
+- 至少支持：
+- 导出当前页
+- 导出指定页数
+- 导出全部结果
+- `验收标准`：
+- 针对多页数据可完成跨页导出
+
+### ++ 12. “是否有备案”筛选需修复
+
+- `当前状态`：`已整改`
+
+- `问题说明`：人工验收中，无论是否勾选备案条件，出现的域名结果均相同。
+- `整改要求`：
+- 核查备案字段写入与筛选逻辑
+- 保证“有备案 / 无备案 / 未检测”条件能真实区分结果集
+- `验收标准`：
+- 构造不同备案状态数据后，筛选结果明显区分
+
+### ++ 13. 批量更新选中域名功能需修复
+
+- `当前状态`：`已整改`
+
+- `问题说明`：人工验收中，已选中域名后执行批量更新，系统提示“成功更新0个域名的信息”。
+- `整改要求`：
+- 修复选中项识别、域名定位、更新提交逻辑
+- 保证选中数据可真正更新到数据库
+- `验收标准`：
+- 选择多条域名执行批量更新后，数据库与界面结果同步变化
+
+### ++ 14. 检测选项配置中需补充时光机检测
+
+- `当前状态`：`已整改`
+
+- `问题说明`：人工验收中指出系统设置的检测选项中没有“时光机检测”，但需求流程中时光机属于基础检测步骤。
+- `整改要求`：
+- 在检测选项配置中增加“时光机检测”开关
+- 并确保该开关与实际流程联动
+- `验收标准`：
+- 关闭时光机后流程不执行时光机检测
+- 开启后流程正常执行并写入结果
+
+---
+
+## 三、二类问题（建议整改）
+
+### 8. 时光机检测已按当前验收口径调整为“全快照倒序扫描标题，命中即停”
+
+- `当前状态`：`已整改，待复测确认`
+
+- `当前情况`：已使用 Wayback/CDX API 获取全量快照时间戳，并按倒序进行扫描。
+- `当前实现`：
+- 仅抓取快照 `title`
+- 按 `title` 去重
+- 先快速检查最新快照，命中后不再继续拉取全量快照列表
+- 使用 CDX 返回的 `digest` 先做内容级去重，减少重复 title 请求
+- 命中敏感词立即停止后续扫描
+- 已增加标题缓存与时间戳列表缓存
+- `保留说明`：当前不再按正文提取友链数量；如甲方仍要求自动产出友链数，需另行补充正文抓取或其他统计来源。
+- `备注`：该实现已与当前人工审核口径一致，即必须检查全部快照，但命中后立即停止。
+
+### 9. “友链数量是否大于 10”建议接入自动检测闭环
+
+- `当前状态`：`已整改`
+
+- `当前情况`：已有相关字段与部分处理逻辑。
+- `存在差距`：与自动检测、筛选条件、落库逻辑的衔接还不完整。
+- `整改建议`：
+- 自动检测时计算并回写友链结果
+- 筛选页支持按该结果稳定筛选
+
+### 10. 人工筛选规则脚本化建议进一步补齐
+
+- `当前状态`：`整改中`
+
+- `需求涉及平台`：
+- 站长之家
+- 爱站
+- 百度 site
+- 360 site
+- 聚查 WHOIS/备案/拦截
+- 桔子 SEO 历史/外链
+- `当前情况`：已有平台检测器，但规则覆盖不完整。
+- `整改建议`：
+- 逐项补齐需求文档中已列明的业务判断规则
+- 能自动拉黑的规则尽量自动化，不保留人为口径歧义
+
+### 11. 检测端稳定性建议优化
+
+- `当前状态`：`已完成一轮基础整改，待长时压测`
+
+- `当前情况`：项目可运行，但数据库连接、线程模型、失败重试等仍有优化空间。
+- `整改建议`：
+- 优化连接池与并发参数
+- 梳理失败重试与日志
+- 降低因资源配置导致的不稳定情况
+
+### 12. 配置写入逻辑建议优化
+
+- `当前状态`：`已整改`
+
+- `当前情况`：系统设置页在初始化过程中存在重复写本地文件/Redis 的现象。
+- `整改建议`：
+- 初始化加载与主动保存行为区分
+- 减少无效写入与重复日志
+
+### 13. 明文密码存储建议整改
+
+- `当前状态`：`已整改`
+
+- `当前情况`：本地存在明文账号密码保存。
+- `整改建议`：
+- 明确是否允许本地持久化保存
+- 若允许，应增加最基本的保护措施
+- 若不允许，应移除明文存储
+
+---
+
+## 四、三类问题（可阶段处理）
+
+### 14. 多来源采集扩展
+
+- `当前状态`：`暂缓`
+
+- `包含项`：
+- 搜索引擎采集
+- 企业目录采集
+- Zone File 采集
+- 第三方 API / 数据包接入
+- `说明`：该类功能对“全网增量建设”有价值，但可根据当前项目阶段单独排期。
+
+### 15. Redis Bloom 模块支持
+
+- `当前状态`：`暂缓`
+
+- `当前情况`：Redis 当前可正常使用，但未安装 Bloom 模块。
+- `说明`：不影响当前基础运行，可后续视大数据量需求决定是否补充。
+
+### 16. 亿级数据量专项优化
+
+- `当前状态`：`暂缓`
+
+- `说明`：需求文档中有“支持亿级数据量”的目标，当前项目尚不足以证明已达到该级别设计要求。
+- `建议后续处理方向`：
+- 索引优化
+- 批量导入策略
+- 分区/分表设计
+- 大规模调度与队列方案
+
+### 17. 交互体验优化
+
+- `当前状态`：`整改中`
+
+- `包含项`：
+- 批量操作反馈
+- 查询空结果提示
+- 导出结果提示
+- 状态说明更清晰
+- `说明`：可在主流程稳定后再安排
+
+---
+
+## 五、建议整改优先级
+
+建议外包方按以下顺序整改：
+
+1. 检测任务闭环
+2. 检测结果回写
+3. 状态码统一
+4. TXT 导出
+5. 筛选条件真实生效
+6. 敏感词配置全链路生效
+7. 停止规则补齐
+8. 时光机升级
+9. 人工筛选规则补齐
+10. 稳定性与安全性优化
+
+---
+
+## 六、复测建议
+
+整改完成后，建议按以下顺序重新复测：
+
+1. 环境连接与数据库初始化
+2. 域名导入与去重
+3. 自动创建检测任务
+4. 注册状态检测
+5. 时光机检测
+6. 平台深度检测
+7. 结果回写数据库
+8. 筛选页面结果准确性
+9. 批量更新使用状态/人工复核状态
+10. TXT 导出正确性
+
+---
+
+## 七、外包方回复建议格式
+
+请外包方按以下格式逐项回复：
+
+- `问题编号`
+- `是否认可`
+- `是否已整改`
+- `整改说明`
+- `涉及文件`
+- `预计完成时间`
+
+---
+
+## 八、当前阶段结论
+
+当前版本不建议直接整体验收通过。  
+建议以本清单为基础，由外包方完成一类问题整改后，再进入下一轮正式复测。

docs/04_domainCheck_WebLinux改造总体方案.md

@@ -0,0 +1,604 @@
+# domainCheck Web/Linux 改造总体方案
+
+## 一、目标结论
+
+本项目建议采用“双轨过渡”方案：
+
+- `现阶段`：保持当前 `Windows 桌面版` 不变，继续测试、验收、修正业务规则
+- `目标形态`：新增一套 `轻量 Web 管理后台 + Linux 后端 API + Linux 检测 Worker`
+- `过渡策略`：桌面版与 Web 版共用同一套数据库、Redis、检测规则与任务模型，逐步把控制面迁移到 Web
+
+本方案的核心原则：
+
+- 不推倒重做现有检测核心
+- 不在当前大型 `admin` 项目里硬改主线
+- 新建一套轻量 Web 管理后台，只覆盖 `domainCheck` 真实需要的页面
+- 将桌面端中的“配置、任务控制、日志查询、导入导出”逐步抽为后端 API
+- 将检测执行从 GUI 进程迁移为 Linux 常驻 Worker
+
+---
+
+## 二、为什么采用这条路线
+
+### 1. 当前桌面版的价值仍然存在
+
+当前桌面版已经完成了以下高价值资产：
+
+- 域名导入、待检测任务创建、检测结果写库
+- 免费检测链路与付费检测链路
+- Wayback 优化策略
+- 代理池、多线程、命中即停、缓存
+- 域名筛选、导出、批量更新
+- 现有数据库结构与状态体系
+
+这些能力不应废弃，后续 Web 化应尽量复用。
+
+### 2. Linux 长期最优形态不是桌面打包工具
+
+Linux 更适合：
+
+- 跑 PostgreSQL / Redis
+- 跑 API 服务
+- 跑常驻 Worker
+- 跑定时任务与日志分析
+
+Linux 不适合长期承载 PySide6 桌面 GUI 作为运营入口。
+
+### 3. 轻量 Web 后台比继续清理现有 admin 更可控
+
+当前 `admin` 项目本质上是一个成熟后台壳，但它：
+
+- 带有原业务的大量历史模块
+- 接口风格偏向既有 ThinkPHP 体系
+- 动态菜单、权限、接口命名、Token 机制均带旧耦合
+
+因此更适合“参考其基础能力”，而不是作为 `domainCheck` 的长期主线代码仓。
+
+---
+
+## 三、目标架构
+
+建议拆成 4 层：
+
+### 1. Web 管理后台
+
+技术建议：
+
+- `Vue 3`
+- `Vite`
+- `Element Plus`
+- `Pinia`
+- `Vue Router`
+
+职责：
+
+- 登录
+- 系统设置
+- 域名导入
+- 检测控制
+- 域名筛选
+- 导出
+- 日志诊断
+
+说明：
+
+- Web 端只做“控制面”和“展示面”
+- 不直接承担检测执行
+
+### 2. 后端 API 服务
+
+技术建议：
+
+- 延续当前 Python 技术栈，优先考虑 `FastAPI`
+
+职责：
+
+- 用户登录鉴权
+- 配置读写
+- 导入任务接口
+- 检测控制接口
+- 域名筛选查询接口
+- 导出任务接口
+- 日志诊断接口
+- Worker 状态汇总接口
+
+### 3. Linux 检测 Worker
+
+技术建议：
+
+- Python 常驻服务
+- 无 GUI
+- systemd 托管
+
+职责：
+
+- 从数据库或任务表领取待检测域名
+- 按配置顺序执行免费检测与付费检测
+- 写回检测结果与黑名单信息
+- 汇报运行状态、进度、异常、代理池状态
+
+### 4. 数据与基础设施层
+
+- `PostgreSQL`
+- `Redis`
+- 日志文件
+- 可选对象存储或文件目录用于导出文件
+
+---
+
+## 四、推荐的总体模块划分
+
+### 1. `domain-web`
+
+前端项目，负责：
+
+- 登录页
+- 仪表盘
+- 系统设置
+- 域名管理
+- 检测控制台
+- 日志诊断页
+
+### 2. `domain-api`
+
+后端 API 服务，负责：
+
+- `auth`
+- `settings`
+- `domains`
+- `detect`
+- `exports`
+- `logs`
+- `diagnostics`
+
+### 3. `domain-worker`
+
+检测 Worker，负责：
+
+- 检测任务轮询
+- 并发检测
+- 代理使用
+- 日志写入
+- 运行状态上报
+
+### 4. `domain-core`
+
+可复用核心库，负责：
+
+- 数据库访问
+- 状态码定义
+- 检测器封装
+- 导入、筛选、导出服务
+- 配置对象
+- 公共异常与日志工具
+
+说明：
+
+- 当前 `domainCheck` 的大部分核心逻辑，后续应逐步沉淀到这一层
+- 这是兼容桌面版与 Web/Linux 双模式的关键
+
+---
+
+## 五、页面范围
+
+第一期轻量 Web 后台建议只做以下页面：
+
+### 1. 登录
+
+- 用户登录
+- Token 持久化
+- 退出登录
+
+### 2. 系统设置
+
+- 数据库连接信息只读或隐藏
+- 检测选项配置
+- 检测顺序调整
+- 代理池配置
+- 允许直连开关
+- 线程数配置
+- 聚名 / 聚查 Cookie 管理
+- 敏感词配置管理
+
+### 3. 域名导入
+
+- 上传 TXT
+- 导入结果反馈
+- 导入失败明细
+- 自动建待检测任务
+
+### 4. 检测控制
+
+- 启动检测
+- 停止检测
+- Worker 在线状态
+- 当前线程数
+- 当前代理状态
+- 当前任务进度
+
+### 5. 域名筛选
+
+- 注册状态
+- 检测状态
+- 使用状态
+- 是否备案
+- 备案年份
+- 快照年份
+- backlink > 10
+- 关键词、域名、首页网址
+- 分页列表
+
+### 6. 导出
+
+- 导出 TXT
+- 导出 CSV/Excel
+- 导出当前页 / 指定页数 / 全部
+- 导出任务记录
+
+### 7. 日志诊断
+
+- Worker 运行日志
+- API 错误日志
+- 最近异常摘要
+- 一键诊断分析
+
+---
+
+## 六、后端拆分建议
+
+后端改动不是重写业务，而是“服务化”。
+
+### 1. 可直接复用的部分
+
+- 检测器逻辑
+- 状态码与状态映射
+- 域名导入核心逻辑
+- 筛选 SQL 逻辑
+- 导出逻辑
+- Wayback 优化逻辑
+- 代理池逻辑
+- 数据库表结构
+
+### 2. 需要抽离成 service 的部分
+
+- 系统设置读写
+- 检测选项配置读写
+- 线程数配置读写
+- 代理配置读写
+- Cookie 配置读写
+- 域名导入服务
+- 域名筛选服务
+- 导出服务
+- 日志读取与诊断服务
+
+### 3. 需要从 GUI 中搬出的部分
+
+- 检测启动/停止逻辑
+- 运行状态展示逻辑
+- 配置变更监听
+- GUI 信号槽驱动的线程控制
+
+### 4. 需要新增的部分
+
+- API 鉴权
+- API 返回结构统一
+- Worker 心跳机制
+- 导出任务记录
+- 日志分析接口
+- 远程诊断接口
+
+---
+
+## 七、并发架构建议
+
+当前并发能力可以复用，但调度外壳要改。
+
+### 1. 保留的能力
+
+- 域名级多线程检测
+- 检测顺序控制
+- Wayback 小并发与命中即停
+- 代理池共享
+- 失败重试
+- 结果落库
+
+### 2. 要调整的实现方式
+
+从：
+
+- `QThread + GUI 信号 + 本地窗口状态`
+
+迁移为：
+
+- `Worker 线程池 + 服务状态上报 + API 查询`
+
+### 3. 推荐并发模型
+
+- 单 Worker 实例维护一个检测线程池
+- Worker 从 `detect_tasks` 拉取待处理任务
+- 每个域名仍按当前检测顺序串行执行单域名步骤
+- 多域名并行执行
+- Wayback 继续保留单域名内部的小并发与缓存机制
+
+### 4. 推荐的任务状态流转
+
+- `待检测`
+- `检测中`
+- `检测完成`
+- `检测失败`
+- `已拉黑`
+
+同时保留任务表：
+
+- `status = pending`
+- `status = running`
+- `status = completed`
+- `status = failed`
+
+---
+
+## 八、免费与付费检测执行策略
+
+这部分建议沿用当前已确认规则：
+
+- 先跑免费项
+- 免费项全部跑完且仍非黑名单，才跑付费项
+- 付费项默认为：
+- 聚查
+- 桔子
+
+检测顺序默认建议：
+
+1. 检查注册
+2. 百度 site
+3. 360 site
+4. 站长之家
+5. 爱站
+6. 时光机
+7. 聚查
+8. 桔子
+
+说明：
+
+- Web 后台允许运营勾选与调整顺序
+- 但后端执行器应保留“付费项后置”的保护规则
+
+---
+
+## 九、代理架构建议
+
+### 1. 保留现有能力
+
+- 多代理池 URL
+- 允许直连开关
+- 抽样代理测试
+- 可用代理数展示
+
+### 2. Linux 后端建议新增
+
+- 代理池刷新冷却时间
+- 空池失败退避
+- 低水位自动补池
+- 按检测步骤控制是否优先直连
+- 代理池健康状态缓存
+
+### 3. 建议策略
+
+- 生产环境：优先代理，谨慎直连
+- 测试环境：允许直连兜底，减少空转
+- 国内服务器：优先使用国内代理池
+
+---
+
+## 十、日志与诊断架构建议
+
+### 1. 日志来源
+
+- API 服务日志
+- Worker 日志
+- 导入日志
+- 导出日志
+- 代理池测试日志
+
+### 2. 日志能力
+
+- Web 页面查看最近日志
+- 关键词过滤
+- 失败任务聚合
+- 一键下载诊断包
+
+### 3. 诊断接口
+
+建议后续提供：
+
+- `POST /diagnostics/analyze`
+- `GET /diagnostics/latest`
+- `GET /logs/worker`
+- `GET /logs/api`
+
+### 4. 上传分析内容建议
+
+- 最近 300 到 500 行日志
+- 当前系统配置快照
+- Worker 状态快照
+- 数据库统计摘要
+
+---
+
+## 十一、认证与权限建议
+
+第一期建议做轻量权限：
+
+- `admin`
+- `operator`
+
+说明：
+
+- `admin` 可修改系统配置、代理、Cookie、敏感词
+- `operator` 只能导入、查看、筛选、导出、启动检测
+
+建议使用：
+
+- JWT 或简单 Token
+- Redis 存储会话
+
+不建议第一期就上过重 RBAC。
+
+---
+
+## 十二、数据库策略建议
+
+当前数据库可继续使用，不建议第一期大改表结构。
+
+建议新增或补强的表可以是：
+
+- `sys_users`
+- `sys_login_logs`
+- `export_tasks`
+- `worker_heartbeats`
+- `diagnostic_reports`
+
+现有核心表继续复用：
+
+- `domains`
+- `detect_tasks`
+- `domain_detections`
+- `domain_blacklist`
+- `sensitive_words`
+
+---
+
+## 十三、兼容双模式方案
+
+目标是兼容：
+
+- `模式 A`：Windows 桌面版
+- `模式 B`：Web 后台 + Linux Worker
+
+兼容方式：
+
+- 共用同一套数据库
+- 共用同一套 Redis
+- 共用同一套状态码与检测规则
+- 共用同一套导入、筛选、导出核心服务
+
+建议：
+
+- 桌面版在过渡期继续可用
+- Web 版逐步接管日常运营
+- 最终桌面版只保留给管理员或完全退役
+
+---
+
+## 十四、实施阶段建议
+
+### 第一阶段：方案冻结
+
+周期建议：`2-3 天`
+
+产出：
+
+- 页面清单
+- API 清单
+- 数据模型确认
+- 迁移边界确认
+
+### 第二阶段：后端服务化
+
+周期建议：`7-12 天`
+
+产出：
+
+- 登录鉴权
+- 配置接口
+- 域名查询接口
+- 导入接口
+- 导出接口
+- 检测控制接口
+- 日志接口
+
+### 第三阶段：Worker Linux 化
+
+周期建议：`5-8 天`
+
+产出：
+
+- 无 GUI Worker
+- systemd 启动方案
+- 心跳上报
+- 任务轮询
+- 并发检测
+
+### 第四阶段：Web 后台一期
+
+周期建议：`7-10 天`
+
+产出：
+
+- 登录
+- 系统设置
+- 域名导入
+- 检测控制
+- 域名筛选
+- 导出
+- 日志诊断
+
+### 第五阶段：联调与回归
+
+周期建议：`5-7 天`
+
+产出：
+
+- API 联调
+- Worker 联调
+- 真实域名回归
+- 性能参数调整
+
+---
+
+## 十五、周期评估
+
+如果基于当前项目逐步演进：
+
+- `较顺利`：`3-4 周`
+- `稳妥完整`：`4-6 周`
+
+前提：
+
+- 当前桌面版继续测试，不同时大规模重构
+- Web 后台走轻量方案，不做额外复杂业务
+- 检测核心尽量复用，不重写规则
+
+---
+
+## 十六、风险点
+
+### 1. GUI 与业务逻辑仍有部分耦合
+
+需要持续把 GUI 里的逻辑搬到 service 层。
+
+### 2. 代理池资源仍是实际瓶颈
+
+Linux 化不会自动解决代理池不足问题，只能让调度更稳。
+
+### 3. 第三方站点反爬与返回结构变动
+
+百度、360、站长、爱站、聚查、桔子都可能发生变化，需要留维护预算。
+
+### 4. Wayback 首次大域名扫描仍可能耗时较高
+
+虽然当前已优化很多，但超大域名首次拉 CDX 列表仍是客观成本。
+
+---
+
+## 十七、最终建议
+
+建议现在就按以下路径推进：
+
+1. 当前桌面版继续测试，不做大方向替换
+2. 新建轻量 Web 后台项目，不在现有 `admin` 大仓上继续主线开发
+3. 新建 API 服务层，承接配置、任务、导入、筛选、导出、日志能力
+4. 将检测端逐步改造成 Linux 常驻 Worker
+5. 保持桌面版与 Web/Linux 双模式并行一段时间
+
+这是当前成本、风险、可维护性三者之间最平衡的方案。

docs/05_domainCheck_Linux部署清单.md

@@ -0,0 +1,142 @@
+# 05 domainCheck Linux 部署清单
+
+## 一、目标形态
+
+- `domain-web`：提供运营管理后台
+- `domain-api`：提供接口、日志、运行中心、导入导出能力
+- `domainCheck`：继续承载检测核心与 Worker
+- `PostgreSQL + Redis`：建议同机或同内网部署
+
+## 二、服务器准备
+
+- 操作系统：Ubuntu 22.04 / Debian 12 / Rocky Linux 9 均可
+- Python：`3.11`
+- Node：仅构建前端时需要，运行静态文件不强依赖
+- PostgreSQL：建议 `14+`
+- Redis：建议 `6+`
+
+## 三、目录建议
+
+```text
+/opt/domaincheck
+├── domain-api
+├── domain-web
+└── domainCheck
+```
+
+## 四、上线前核对
+
+### 1. 数据库
+
+- `domains`
+- `detect_tasks`
+- `domain_detections`
+- `domain_blacklist`
+- `sensitive_words`
+
+确认这几张核心表已经存在。
+
+### 2. Redis
+
+确认可以正常读写：
+
+- `domain_tool:detect_options`
+- `domain_tool:proxy_config`
+- `domain_tool:thread_count`
+
+### 3. Worker 配置
+
+确认 `domainCheck/.env` 已配置：
+
+- `DB_HOST`
+- `DB_PORT`
+- `DB_DATABASE`
+- `DB_USER`
+- `DB_PASSWORD`
+- `REDIS_HOST`
+- `REDIS_PORT`
+- `REDIS_PASSWORD`
+
+### 4. Web/API 配置
+
+确认 `domain-api` 使用：
+
+- `WORKER_MODE=linux-systemd`
+- `WORKER_SERVICE_NAME=domaincheck-worker`
+- `API_SERVICE_NAME=domaincheck-api`
+
+## 五、部署顺序
+
+1. 上传 `domainCheck`
+2. 上传 `domain-api`
+3. 上传 `domain-web`
+4. 创建 Python 虚拟环境并安装依赖
+5. 初始化或连接 PostgreSQL/Redis
+6. 安装 `systemd` 服务
+7. 启动 `domaincheck-api`
+8. 启动 `domaincheck-worker`
+9. 验证 Web 后台与运行中心
+
+### 前端补充
+
+`domain-web` 建议：
+
+1. 复制 `.env.production.example` 为 `.env.production`
+2. 修改 `VITE_API_BASE_URL`
+3. 执行 `deploy/linux/publish.sh`
+4. 使用 `deploy/nginx/domain-web.conf` 配置 Nginx
+
+## 六、上线后验证
+
+### 1. API
+
+访问：
+
+```text
+http://服务器IP:8100/health
+```
+
+### 2. Web 后台
+
+确认能正常完成：
+
+- 登录
+- 系统设置读取
+- 域名筛选查询
+- 导出列表查看
+- 日志诊断查看
+
+### 3. Worker
+
+确认：
+
+- 运行中心显示 Worker 在线
+- 检测控制可读到当前进程数
+- `detect_worker.log` 正常写入
+
+## 七、切换策略
+
+建议按下面顺序平滑切换：
+
+1. `Web 后台` 先接管配置、筛选、导出、日志
+2. `Linux Worker` 再逐步接管检测主任务
+3. `Windows 桌面端` 暂时保留为备用入口
+4. 运行稳定后，再考虑淡出桌面检测端
+
+## 八、当前完成度
+
+截至当前版本，已完成：
+
+- Web 后台主页面
+- API 接口主链路
+- 运行中心
+- Windows 本地 Worker 控制
+- Linux systemd 控制模式支持
+- systemd 模板文件
+
+仍建议上线前重点复测：
+
+- Linux systemd 实机启停
+- Linux 下日志路径与权限
+- 真实代理池在国内服务器上的表现
+- 大批量导入与导出任务表现

docs/06_domainCheck_Web版当前完成度.md

@@ -0,0 +1,75 @@
+# 06 domainCheck Web版当前完成度
+
+## 一、当前已落地
+
+- `domain-web` 已可运行
+- `domain-api` 已可运行
+- `domain-web` 已完成：
+  - 登录
+  - 顶部运行状态头部
+  - 概览
+  - 运行中心
+  - 系统设置
+  - 域名导入
+  - 检测控制
+  - 域名筛选
+  - 批量更新
+  - 导出中心
+  - 日志诊断
+  - 诊断包下载
+  - 配置快照导出/导入
+  - 配置备份创建与备份记录查看
+- `domain-api` 已完成：
+  - 健康检查
+  - 登录
+  - 概览统计
+  - 系统设置读写
+  - 配置快照导出/导入
+  - 配置导入校验
+  - 配置备份与备份列表
+  - 导入任务接口
+  - 检测状态与启停接口
+  - 域名筛选接口
+  - 批量更新接口
+  - 导出记录与生成接口
+  - 日志诊断接口
+  - 运行中心接口
+
+## 二、运行模式
+
+当前已支持双模式：
+
+- `windows-local`
+- `linux-systemd`
+
+其中：
+
+- `Windows 本地模式` 已完成真实联调
+- `Linux systemd 模式` 已完成代码支持、模板文件和部署文档
+
+## 三、部署资料
+
+已具备：
+
+- `domain-api/.env.example`
+- `domain-api/deploy/systemd/domain-api.service`
+- `domain-api/deploy/systemd/domain-worker.service`
+- `domain-api/deploy/linux/README.md`
+- `domain-web/.env.production.example`
+- `domain-web/deploy/nginx/domain-web.conf`
+- `domain-web/deploy/linux/publish.sh`
+- `docs/05_domainCheck_Linux部署清单.md`
+- `docs/07_domainCheck_WebLinux发布验收清单.md`
+- `docs/08_domainCheck_交付说明.md`
+
+## 四、当前仍建议重点复测
+
+- Linux `systemd` 实机启停
+- Linux 下 API / Worker 日志路径与权限
+- 国内服务器上的真实代理池表现
+- 大批量导入与导出任务表现
+- 长时间运行下的 Worker 稳定性
+
+## 五、当前结论
+
+从代码、接口、页面、部署材料四个层面看，这套 Web/Linux 方案已经不是概念原型，而是进入了“可交付、可联调、可继续迁移”的阶段。

docs/07_domainCheck_WebLinux发布验收清单.md

@@ -0,0 +1,90 @@
+# 07 domainCheck Web/Linux 发布验收清单
+
+## 一、基础连通
+
+- `domain-api` 已启动
+- `domainCheck Worker` 已启动
+- `http://服务器IP:8100/health` 返回 `status=ok`
+- `runtime/preflight` 返回 `ok=true`
+
+## 二、Web 后台
+
+- 登录正常
+- 顶部可看到 `API / Worker / 运行模式`
+- 概览页能正常读取统计
+- 运行中心能正常读取：
+  - API 版本
+  - API 前缀
+  - PID
+  - Worker 进程数
+  - 自检结果
+
+## 三、配置能力
+
+- 系统设置能正常读取
+- 线程数修改后可保存
+- 检测顺序可调整并保存
+- 代理池列表可编辑并保存
+- `worker_mode / service_name` 可保存
+- 可手动创建配置备份
+- 可下载配置备份
+- 可导出配置快照
+- 可导入配置快照
+- 导入配置时会自动生成导入前备份
+
+## 四、业务能力
+
+- 导入任务可创建
+- 导入任务列表可刷新
+- 导入任务失败时可重试
+- 域名筛选可查询
+- 批量更新可执行
+- 导出记录可生成
+- 导出文件可下载
+- 日志诊断页可查看日志
+- 诊断包可下载
+
+## 五、Linux 特有项
+
+- `domaincheck-api.service` 可正常启动/停止
+- `domaincheck-worker.service` 可正常启动/停止
+- `journalctl` 可查看两边日志
+- Nginx 反代正常
+- Web 静态文件 `dist` 已正确发布
+
+## 六、建议发布前命令
+
+### 1. 运行 API 自测
+
+```bash
+cd /opt/domaincheck/domain-api
+python deploy/linux/smoke_test.py --base-url http://127.0.0.1:8100
+```
+
+如需同时校验 Web 首页：
+
+```bash
+python deploy/linux/smoke_test.py --base-url http://127.0.0.1:8100 --web-url http://127.0.0.1
+```
+
+### 2. 查看 API 健康状态
+
+```bash
+curl http://127.0.0.1:8100/health
+curl http://127.0.0.1:8100/api/v1/runtime/preflight
+```
+
+### 3. 查看 systemd 状态
+
+```bash
+systemctl status domaincheck-api
+systemctl status domaincheck-worker
+```
+
+## 七、当前结论
+
+如果以上检查项全部通过，则可以认为：
+
+- Web 管理后台已达到可交付状态
+- Linux 部署环境已达到可联调状态
+- 可以进入真实服务器联调或灰度上线阶段

docs/08_domainCheck_交付说明.md

@@ -0,0 +1,122 @@
+# 08 domainCheck 交付说明
+
+## 一、当前交付范围
+
+本次已交付：
+
+- `domainCheck` 桌面版主项目
+- `domain-api` 轻量后端接口服务
+- `domain-web` 轻量运营管理后台
+- Windows 本地联调脚本
+- Linux 部署材料
+- Linux 自检与发布验收文档
+
+## 二、Windows 本地脚本
+
+可直接使用：
+
+- `start_domain_api.ps1`
+- `stop_domain_api.ps1`
+- `start_domain_web.ps1`
+- `stop_domain_web.ps1`
+- `start_domain_web_background.ps1`
+- `start_domain_stack.ps1`
+- `stop_domain_stack.ps1`
+- `smoke_test_stack.ps1`
+
+推荐整套启动：
+
+```powershell
+powershell -ExecutionPolicy Bypass -File .\start_domain_stack.ps1
+```
+
+推荐整套停止：
+
+```powershell
+powershell -ExecutionPolicy Bypass -File .\stop_domain_stack.ps1
+```
+
+推荐整套自测：
+
+```powershell
+powershell -ExecutionPolicy Bypass -File .\smoke_test_stack.ps1
+```
+
+## 三、Web/API 默认地址
+
+- Web：`http://127.0.0.1:3200`
+- API：`http://127.0.0.1:8100`
+
+## 四、配置迁移能力
+
+系统设置页已经支持：
+
+- 手动创建配置备份
+- 下载配置备份
+- 导出当前配置快照
+- 导入配置快照
+
+配置快照内容包括：
+
+- 检测选项和执行顺序
+- 代理配置
+- 线程数
+- Web/API 运行配置
+
+推荐场景：
+
+- Windows 测试环境导出配置
+- Linux 正式环境导入配置
+- 发布前先做一次配置备份
+- 导入配置前系统会自动生成一份导入前备份
+
+## 五、Linux 部署相关
+
+请优先阅读：
+
+- `docs/05_domainCheck_Linux部署清单.md`
+- `docs/07_domainCheck_WebLinux发布验收清单.md`
+- `domain-api/deploy/linux/README.md`
+- `domain-web/README.md`
+
+## 六、上线前建议
+
+### 1. 跑 API 自检
+
+```bash
+cd /opt/domaincheck/domain-api
+python deploy/linux/smoke_test.py --base-url http://127.0.0.1:8100
+```
+
+### 2. 打开运行中心
+
+确认：
+
+- API 在线
+- Worker 在线
+- 运行模式正确
+- 部署自检通过
+
+### 3. 打开日志诊断
+
+确认：
+
+- 可正常查看日志
+- 可正常下载诊断包
+
+### 4. 导出一次配置快照
+
+确认：
+
+- 可以成功下载 JSON 快照
+- 导入后配置能恢复
+
+## 七、当前结论
+
+当前项目已经进入“可交付、可联调、可部署”的状态。
+
+剩余工作重点不再是基础开发，而是：
+
+- Linux 实机联调
+- 上线前复测
+- 真实服务器灰度验证

docs/09_domainCheck_交付打包说明.md

@@ -0,0 +1,111 @@
+# 09 domainCheck 交付打包说明
+
+## 一、用途
+
+用于在 Windows 本地把当前可交付内容整理成一份压缩包，便于：
+
+- 发给运维或部署同事
+- 存档版本快照
+- 迁移到 Linux 服务器前做交付留档
+
+## 二、打包脚本
+
+根目录脚本：
+
+- `package_domain_release.ps1`
+- `verify_domain_release.ps1`
+- `prepare_final_release.ps1`
+- `show_latest_release.ps1`
+
+执行方式：
+
+```powershell
+powershell -ExecutionPolicy Bypass -File .\package_domain_release.ps1
+```
+
+如需一键完成“打包 + 验包 + 生成最终准备报告”：
+
+```powershell
+powershell -ExecutionPolicy Bypass -File .\prepare_final_release.ps1
+```
+
+如需快速查看当前最新交付物：
+
+```powershell
+powershell -ExecutionPolicy Bypass -File .\show_latest_release.ps1
+```
+
+## 三、输出位置
+
+打包后会生成：
+
+- `release/domaincheck_release_时间戳/`
+- `release/domaincheck_release_时间戳.zip`
+- `release/domaincheck_release_时间戳.sha256.txt`
+- `release/latest_release.txt`
+- `release/latest_release.json`
+- `release/final_release_report.json`
+
+## 四、当前会包含的内容
+
+- `docs/`
+- `scripts/`
+- `domain-api/`
+  - `app`
+  - `deploy`
+  - `README.md`
+  - `requirements.txt`
+  - `.env.example`
+- `domain-web/`
+  - `src`
+  - `deploy`
+  - `README.md`
+  - `package.json`
+  - `package-lock.json`
+  - `tsconfig`
+  - `vite.config.ts`
+  - `.env.example`
+  - `.env.production.example`
+  - 若存在则带上 `dist`
+
+同时会生成：
+
+- `release_manifest.json`
+- `README_RELEASE.txt`
+- `smoke_test_report.json`
+  - 若打包时本机 Web/API 正常运行，则自动生成并随包带出
+- `.sha256.txt`
+  - 用于校验 zip 交付包完整性
+
+## 五、建议使用顺序
+
+1. 先阅读 `docs/08_domainCheck_交付说明.md`
+2. 查看 `release_manifest.json`
+3. 查看 `smoke_test_report.json`
+4. 核对 `.sha256.txt`
+   或执行：
+
+```powershell
+powershell -ExecutionPolicy Bypass -File .\verify_domain_release.ps1
+```
+
+5. Windows 联调先跑 `scripts/smoke_test_stack.ps1`
+6. Linux 部署前阅读：
+   - `docs/05_domainCheck_Linux部署清单.md`
+   - `docs/07_domainCheck_WebLinux发布验收清单.md`
+   - `domain-api/deploy/linux/README.md`
+
+## 六、说明
+
+当前打包内容偏向“交付部署包”和“源代码归档包”，不包含：
+
+- `node_modules`
+- Python 虚拟环境
+- 临时运行日志
+- 数据库数据本体
+
+这样更适合交付、存档和迁移。
+
+`latest_release.txt / latest_release.json` 用于快速定位“当前最新一份交付包”，避免人工翻目录。
+
+`final_release_report.json` 用于记录最近一次“打包 + 验包”的最终状态。

docs/10_domainCheck_最终交付结论.md

@@ -0,0 +1,67 @@
+# 10 domainCheck 最终交付结论
+
+## 一、当前结论
+
+当前项目已经完成从桌面版能力梳理，到 Web/API 方案落地，再到部署、验收、打包、验包的完整闭环。
+
+从“可用性、可运维性、可交付性”三个维度看，当前状态可以定义为：
+
+- 可开发使用
+- 可本地联调
+- 可 Linux 部署
+- 可打包交付
+- 可验包校验
+
+## 二、已经具备的核心交付能力
+
+- `domainCheck` 桌面版原系统
+- `domain-api` 轻量后端接口
+- `domain-web` 轻量运营后台
+- Windows 本地启停脚本
+- Linux 部署模板与说明
+- 运行中心
+- 日志诊断
+- 诊断包下载
+- 配置快照导出/导入
+- 配置备份、备份记录、备份下载
+- 配置导入前自动备份
+- API 自检
+- Web/API 整栈自测
+- 交付打包脚本
+- 交付验包脚本
+- SHA256 完整性校验
+- 最新交付指针文件
+
+## 三、当前最新交付物定位方式
+
+可优先查看：
+
+- `release/latest_release.txt`
+- `release/latest_release.json`
+
+它们会指向：
+
+- 最新展开目录
+- 最新 zip 包
+- 最新 sha256 文件
+- 最新自测状态
+
+## 四、剩余工作性质
+
+当前剩余事项已经不再属于“系统开发未完成”，而主要属于：
+
+- 真实 Linux 服务器联调
+- 真实代理池和网络环境验证
+- 上线前灰度发布
+- 发布后观察期
+
+## 五、建议下一步
+
+1. 把最新交付包发送到目标 Linux 服务器
+2. 按 `docs/05`、`docs/07`、`docs/08` 的顺序执行部署与验收
+3. 部署完成后再做一次真实环境 smoke test
+4. 进入灰度上线
+
+## 六、最终判断
+
+当前这套项目，已经达到“工程交付完成，待真实环境上线联调”的状态。

docs/11_domainCheck_Linux联调输入清单.md

@@ -0,0 +1,83 @@
+# 11 domainCheck Linux 联调输入清单
+
+## 一、用途
+
+当项目部署到真实 Linux 服务器后，如果需要我继续协助联调，优先给我下面这些材料。
+
+这样我可以最快定位是：
+
+- systemd 配置问题
+- Python 环境问题
+- Redis/PostgreSQL 连通性问题
+- Web/API 路径配置问题
+- Worker 运行问题
+
+## 二、最推荐的做法
+
+优先在 Linux 服务器执行：
+
+```bash
+cd /opt/domaincheck/domain-api/deploy/linux
+bash collect_diagnostics.sh /opt/domaincheck
+```
+
+执行后会输出：
+
+- `diagnostics_dir=...`
+- `diagnostics_archive=...`
+
+把生成的压缩包发我即可。
+
+## 三、如果不方便发整包，至少给这些
+
+### 1. 服务状态
+
+```bash
+systemctl status domaincheck-api --no-pager
+systemctl status domaincheck-worker --no-pager
+```
+
+### 2. 最近日志
+
+```bash
+journalctl -u domaincheck-api -n 200 --no-pager
+journalctl -u domaincheck-worker -n 200 --no-pager
+```
+
+### 3. 接口状态
+
+```bash
+curl http://127.0.0.1:8100/health
+curl http://127.0.0.1:8100/api/v1/runtime/preflight
+curl http://127.0.0.1:8100/api/v1/runtime/status
+```
+
+### 4. 环境配置
+
+- `domainCheck/.env`
+- `domain-api/.env`
+- `domain-api/runtime/` 下的配置与状态文件
+
+注意：密码和 cookie 可以打码后再发。
+
+## 四、建议一起补充的信息
+
+- 服务器系统版本
+- Python 版本
+- PostgreSQL 版本
+- Redis 版本
+- 是否在中国大陆服务器
+- 是否使用代理池
+- Web 访问域名或端口
+
+## 五、当前仓库已准备好的相关文件
+
+- `domain-api/deploy/linux/README.md`
+- `domain-api/deploy/linux/smoke_test.py`
+- `domain-api/deploy/linux/collect_diagnostics.sh`
+- `docs/05_domainCheck_Linux部署清单.md`
+- `docs/07_domainCheck_WebLinux发布验收清单.md`
+
+## 六、结论
+
+后面你只要把 Linux 环境里的诊断包或上述输出给我，我就可以直接进入最后的线上联调阶段，不需要重新铺背景。 

docs/12_domainCheck_导航索引.md

@@ -0,0 +1,84 @@
+# 12 domainCheck 导航索引
+
+## 一、最常用入口
+
+### 1. 最新交付物
+
+- 最新交付包：`release/latest_release.json`
+- 最新摘要：`release/latest_release.txt`
+- 最终准备报告：`release/final_release_report.json`
+
+### 2. 最终结论文档
+
+- `docs/10_domainCheck_最终交付结论.md`
+
+### 3. Linux 联调时给我的材料
+
+- `docs/11_domainCheck_Linux联调输入清单.md`
+
+## 二、文档阅读顺序
+
+### 1. 先看总体方案
+
+- `docs/04_domainCheck_WebLinux改造总体方案.md`
+
+### 2. 再看交付与部署
+
+- `docs/08_domainCheck_交付说明.md`
+- `docs/05_domainCheck_Linux部署清单.md`
+- `docs/07_domainCheck_WebLinux发布验收清单.md`
+- `docs/09_domainCheck_交付打包说明.md`
+
+### 3. 如果要回溯历史需求与问题
+
+- `docs/01_domainCheck_验收清单.md`
+- `docs/02_domainCheck_优化清单_待审核.md`
+- `docs/03_domainCheck_整改清单_外包版.md`
+- `docs/06_domainCheck_Web版当前完成度.md`
+
+## 三、最常用脚本
+
+### 1. Windows 本地启停
+
+- `start_domain_stack.ps1`
+- `stop_domain_stack.ps1`
+- `smoke_test_stack.ps1`
+
+### 2. 交付打包
+
+- `package_domain_release.ps1`
+- `verify_domain_release.ps1`
+- `prepare_final_release.ps1`
+- `show_latest_release.ps1`
+
+## 四、Linux 侧关键文件
+
+### 1. API/Worker 部署
+
+- `domain-api/deploy/systemd/domain-api.service`
+- `domain-api/deploy/systemd/domain-worker.service`
+- `domain-api/deploy/linux/README.md`
+- `domain-api/deploy/linux/smoke_test.py`
+- `domain-api/deploy/linux/collect_diagnostics.sh`
+
+### 2. Web 部署
+
+- `domain-web/deploy/nginx/domain-web.conf`
+- `domain-web/deploy/linux/publish.sh`
+
+## 五、当前最新状态
+
+当前这套项目已经完成：
+
+- 本地开发
+- Web/API 落地
+- 自检/自测
+- 配置迁移与备份
+- 打包与验包
+- 最终发布准备
+
+剩余工作只在真实 Linux 环境：
+
+- 部署
+- 联调
+- 灰度上线

docs/_tmp_regression/import_regression.txt

@@ -0,0 +1,5 @@
+codex-import-reg-20260416-a.com
+codex-import-reg-20260416-b.net
+http://codex-import-reg-20260416-c.org/path
+bad domain
+codex-import-reg-20260416-a.com

docs/_tmp_regression/regression_domains.txt

@@ -0,0 +1,2 @@
+codex-regression-20260416-a.com
+codex-regression-20260416-b.net

docs/_tmp_regression/regression_page1.csv

@@ -0,0 +1,3 @@
+域名,注册状态,使用状态,检测状态,人工复核状态,过期时间,单位性质,网站首页网址,检测时间,备案历史,备案年份,快照年份,百度历史,百度Site,是否中文标题,360 Site,Google Site,友情链接数量
+codex-regression-20260416-a.com,2,0,1,0,,,https://alpha.example,2026-04-16 10:00:00,2,2024,"2021,2024",{'status': True},{'status': True},,{'status': True},{'status': False},15
+codex-regression-20260416-b.net,2,0,1,0,,,https://beta.example,2026-04-16 11:00:00,3,,2020,{'status': False},{'status': False},,{'status': False},{'status': False},5