DevPortal 后续优化清单（计划）
说明：此文件仅用于记录后续要做的任务与验收标准；在你明确说“开始做第 X 项”之前，不进入代码开发。
优先级约定
- P0：必须做 / 高收益 / 风险控制
- P1：体验增强（效率与可用性）
- P2：质量与长期维护（可持续迭代）
- P3：流程与运维（减少踩坑）
待办任务（17 项）
P0（必须做/高收益）
[x] P0-1 文本 Tab 不默认展示解析预览表
- 目标：文本 Tab 以“原文查看”为主，解析预览统一放到“批量导入弹窗”里。
- 验收：
- 文本 Tab 顶部只保留“识别/已存在/可导入”汇总 + 导入按钮（从当前文本/粘贴覆盖）。
- 不在文本 Tab 展示解析预览表格（或默认折叠且不占空间）。
- 解析预览与编辑仍可在“批量导入弹窗”完成。
[x] P0-2 部署脚本强校验扩展 Key
- 目标：避免上线后插件报
Server not configured。 - 验收：
server-deploy.sh在首次部署/更新前检查.env是否包含DEVPORTAL_EXTENSION_API_KEY。- 缺失时明确提示需要配置，并给出示例值/说明。
- 目标：避免上线后插件报
[ ] P0-3 账号唯一性约束（DB 层）【延期/可选】
- 说明：当前为内部系统，暂不强制 DB 唯一；先依赖应用层去重与“已存在/重复”提示，允许少量重复由用户手动清理。
- 目标（如后续需要再做）：彻底杜绝并发/多端导入导致重复账号。
- 验收（如后续需要再做）：
- 数据库添加唯一索引：
account(module_id, account, password)。 - 导入/新增若触发冲突，前端提示友好（不影响其它成功项）。
- 数据库添加唯一索引：
P1（体验增强）
[x] P1-4 批量导入弹窗：状态筛选/仅看“将导入”
- 目标：数据多时更快定位需要导入的条目。
- 验收：
- 支持筛选：将导入 / 已存在 / 重复 / 无效（至少“仅看将导入”）。
[x] P1-5 单条导入后行内即时状态更新
- 目标：用户导入一条后能立刻看到该条变更（无需心里记忆）。
- 验收：
- 单条导入成功后，该行状态立即变为“已存在”，并禁用“导入”按钮（或自动移出“将导入”视图）。
[x] P1-6 批次备注策略更清晰（文案/开关）
- 目标：避免用户误解“会覆盖已有账号备注/描述”。
- 验收：
- 在导入弹窗中明确说明：仅新增写入
remark/accountInfo，不会覆盖已存在记录（或提供可选策略）。
- 在导入弹窗中明确说明：仅新增写入
[x] P1-7 导入弹窗支持“拆分一条为多条”
- 目标：当解析把多条合成一条时，可在导入弹窗里手动拆分成多条不同账号/密码。
- 验收：
- 每行提供“拆分”入口，支持粘贴多行内容并解析成多条。
- 支持格式：
账号 密码（空格/Tab）、账号/密码、两行一组账号\n密码。 - 拆分后条目可编辑、可单条导入/整批导入，且仍按状态标记与筛选工作。
[ ] P1-8 深色模式体验：ProjectSite 环境色更柔和
- 背景：当前默认浅色为主，但深色模式仍应保持可读与一致；避免环境 Tag/跳转按钮在深色下过亮刺眼。
- 目标：在
ProjectSite中让环境 Tag 与主操作色在深色模式下更协调，同时保留“快速识别”的语义色。 - 验收：
app/projectSite/ProjectSiteContent.tsx的环境 Tag/跳转按钮在浅色/深色均清晰且不突兀（对比度足够）。- 避免在
ProjectSite里新增零散硬编码色；优先使用 Antd token（语义色）或统一的 CSS 变量。
[x] P1-9 Apifox 推送日志：按项目保留最近 10 条
- 背景：Apifox 日志用于快速查看“最近推送是否成功”，无审计要求；按天保留在高频推送场景下不稳定。
- 目标：控制日志表增长，并让首页/列表始终保留“每个项目最新的一小段历史”用于排查。
- 验收：
- 对每个项目仅保留最近 10 条推送日志（超出部分按时间从旧到新清理）。
- 清理过程分批执行，避免长时间锁表/影响正常写入。
- 清理任务可配置开关（是否启用）与保留条数（默认 10）。
[x] P1-10 Apifox 日志页：手动清理入口（按项目保留 N 条）
- 背景：虽然已支持“写入即清理”，但运维/排障时仍需要一个可控的“手动清理”入口，尤其用于历史数据一次性瘦身。
- 目标：在 Apifox 日志页面提供安全的清理操作入口，并展示清理结果摘要。
- 验收：
- 在
/apifox-logs页面提供“清理日志”按钮（带二次确认）。 - 触发后执行一次全库清理：对每个项目保留最近
DEVPORTAL_APIFOX_LOG_KEEP_PER_PROJECT条（默认 10）。 - 返回并展示清理摘要（清理了多少条、涉及多少项目、耗时/时间戳）。
- 提供最小权限/安全限制（例如仅管理员可见/需服务端校验开关），避免误操作或被滥用。
- 在
P2（质量与长期维护）
[x] P2-7
accountInfo推荐填写规范- 目标：让插件/列表能稳定区分多账号。
- 验收：
- 给出推荐格式与示例（如：
系统-角色-地区），并在 UI 提示/占位符中体现。
- 给出推荐格式与示例（如：
[ ] P2-8 解析规则迭代机制（样例库/黑白名单）
- 目标：让“文本解析”可持续提升，不靠拍脑袋改规则。
- 验收：
- 形成样例收集方式（失败样例/误判样例）。
- 支持最小的规则迭代（黑名单/白名单或特殊格式优先级）。
[ ] P2-9 插件填充失败兜底（手动选择输入框）
- 目标：复杂登录页也能用（失败时可控）。
- 验收：
- 自动填充失败时，提供“选择账号框/密码框”的交互兜底（只在失败时出现）。
[ ] P2-11 ESLint/类型治理（清理现存报错 + 规则合理化）
- 背景：当前项目存在较多
any、hooks 规则等 lint 报错；并且需要确保构建产物目录不会被扫描（如.next-prod）。 - 目标：让
pnpm lint可持续作为质量门禁，而不是“每次都大量报错”。 - 验收：
.next-prod等构建产物已从 lint 扫描中排除（忽略规则到位）。- 逐步减少 TS/Hook 相关报错数量（按模块分批清理），不阻塞主功能迭代。
- 明确哪些规则必须遵守、哪些允许临时放行（有清晰的 TODO/时间点）。
- 背景：当前项目存在较多
[ ] P2-12 模块地址可达性检测（延期/可选）
- 背景：模块
moduleUrl同时存在内网/外网；若部署服务器无法访问内网地址，定时检测会产生大量“误报”并增加运维成本。 - 目标：在明确网络可达性前置条件与安全策略（避免 SSRF）后，再引入“地址可达性检测”能力。
- 验收（如后续决定开发）：
- 定义“可达”口径：HTTP 可响应（2xx/3xx/401/403）视为可达；DNS/连接/超时/TLS 失败视为不可达（404 口径待定）。
- 明确网络前置：服务器对内网地址的连通性与域名白名单策略（仅 http/https）。
- 优先支持手动检测（按钮触发 + 结果展示），再考虑定时全量检测与并发控制。
- 背景：模块
[ ] P2-13 /middle 与后台视觉体系统一（延期/可选）
- 背景：当前
/middle使用 Tailwind + 自定义surface-card，而后台页基于 Ant Design Layout/Card；整体易出现“像两个产品”的割裂感。 - 目标：统一边距、背景、卡片与按钮的视觉语言（可选方案：让
/middle也进入MainLayout；或抽象统一的 token/CSS 变量并复用）。 - 验收：
/middle与后台页在浅色/深色下的背景与卡片层级一致（不突兀）。- Header / Content 的留白规则统一（不出现一页紧一页松）。
- 交互反馈一致（hover/active/cursor 等）。
- 背景：当前
P3（流程与运维）
[ ] P3-10 发布前检查清单
- 目标：把“容易踩坑的点”沉淀成流程。
- 验收：
- 一份可执行的检查项：Prisma generate、build、环境变量、插件 Key 一致性、容器重建方式等。
[ ] P3-11 Apifox 日志清理：cron 定时任务（可选）
- 背景：多数情况下“写入即清理”已足够；但在低频推送/历史积累场景，定时任务可作为兜底手段。
- 目标：提供一份可复制的 cron 示例，用于定时执行
pnpm cleanup:apifox-logs。 - 验收：
- 文档提供 cron 示例（如每天凌晨 3 点执行），并说明日志输出/失败告警建议。
- 明确前置：服务器能访问数据库，且
DEVPORTAL_APIFOX_LOG_CLEANUP_ENABLED=true。