用户反馈现象
用户在 MySQL 修复中心看到类似提示：
但用户实际使用 MySQL 没有明显问题，因此产生疑问：
- 为什么软件判断我的 MySQL 出现问题？
- 我明明能正常使用，是不是软件误报？
- 还是说 MySQL 内部确实有潜在问题，只是我平时使用感觉不到？
- 软件应该说明到底基于什么证据判断，而不是直接给出“系统库缺失或不完整”的结论。
问题判断
这是 MySQL 修复中心诊断理由不透明 / 健康判定可能过度激进 / 疑似误报 / 高危修复确认不足 的问题。
MySQL 能正常使用，并不一定代表 Data 目录完全健康；但如果软件只看文件夹或某些系统库目录，就直接提示“系统库缺失或不完整”，也可能误导用户。
因此本 issue 的核心目标不是新增 MySQL 修复功能，而是让诊断更可信、更保守、更可恢复：
证据明确
风险分级
结论保守
默认只读
强制备份
三次确认
先验证再修复
修复后再验证
能区分真实故障、潜在风险和疑似误报
能告诉用户“你是对的还是软件是对的”
可能原因分析
软件可能因为以下证据之一判断异常：
- datadir 下缺少
mysql 系统库目录。
mysql 系统库目录存在但关键文件缺失。performance_schema / sys / mysql 等系统 schema 不完整。- my.ini 中 datadir 指向的路径与实际运行服务不一致。
- 服务注册的 mysqld 路径与当前检测到的 mysqld 路径不一致。
- 存在多个 MySQL 安装，软件检查了一个旧 datadir，但用户实际使用的是另一个实例。
- MySQL 服务运行正常，但软件没有做连接验证，只做了文件系统静态判断。
- 权限不足导致系统库文件无法读取，被误判为缺失。
- MySQL 8.x 与 5.x 的系统库结构差异导致误判。
- Docker / WSL / XAMPP / phpStudy / Laragon / MariaDB 等环境被误判为普通本机 MySQL。
影响范围
该问题可能影响：
- MySQL 修复中心。
- 本地服务检查。
- 数据库服务状态卡片。
- MySQL 1067 / 服务丢失诊断。
- my.ini basedir / datadir 检测。
- Data 目录修复计划。
- 系统库补回计划。
- 服务注册 / 删除 / 重建计划。
- 软件著作权材料中的“数据库修复”功能描述可信度。
修复目标
MySQL 修复中心必须从“结论式提示”改为“证据式诊断”。
不要直接显示：
应改为：
发现 MySQL Data 目录存在疑似系统库风险。
该判断基于以下证据：...
当前 MySQL 服务是否仍可连接：...
当前业务库是否可见：...
该问题属于：真实故障 / 潜在风险 / 疑似误报 / 权限不足无法判断。
一、诊断必须分层
MySQL 诊断至少分为三层：
1. 文件系统静态检查
检查：
- basedir 是否存在。
- datadir 是否存在。
- my.ini 是否存在。
- datadir 下是否存在
mysql、performance_schema、sys 等目录。
- 关键文件是否可读。
- datadir 权限是否足够。
但文件系统检查只能得出“疑似风险”，不能单独得出“数据库不可用”。
2. 服务与进程检查
检查：
- Windows 服务是否存在。
- 服务名。
- 服务状态。
- 服务 BinaryPath。
- mysqld.exe 路径。
- 端口是否监听。
- PID 是否存在。
- 当前运行实例的 basedir/datadir 与 my.ini 是否一致。
3. 连接验证，可选但强烈建议
如果用户提供连接信息或允许使用本机免密/当前配置验证，应检查：
- 能否连接到 MySQL。
SELECT VERSION()。SHOW DATABASES。- 是否能看到
mysql、performance_schema、sys。
- 是否能查询必要系统表，只读。
注意：
- 不记录密码。
- 不保存连接凭据。
- 不读取业务表内容。
- 只做只读验证。
二、诊断结论必须分级
新增或统一 MySQL 健康结论：
Healthy：服务、连接、系统库均正常。
UsableWithWarnings：当前可用，但存在配置不一致或潜在风险。
PotentialRisk：文件系统检查发现疑似风险，但服务仍可用或未做连接验证。
LikelyBroken：服务无法启动且系统库关键项缺失，有较强故障证据。
PermissionUnknown：权限不足，无法判断。
MultipleInstancesAmbiguous：存在多个 MySQL 实例，当前检测对象可能不是用户正在使用的实例。
UnsupportedLayout：Docker/WSL/XAMPP/phpStudy/Laragon/MariaDB 等非标准布局，不能按普通 MySQL Data 修复。
FalsePositiveSuspected：静态检查异常，但连接验证正常，疑似误报。
三、UI 必须展示诊断证据
MySQL 修复中心每个候选项必须展示：
- 服务名。
- 服务状态。
- mysqld 路径。
- my.ini 路径。
- basedir。
- datadir。
- 端口。
- 端口监听进程。
- 静态文件检查结果。
- 连接验证结果。
- 系统 schema 检查结果。
- 风险等级。
- 结论可信度。
- 为什么这么判断。
- 下一步建议。
示例：
结论：当前 MySQL 可用，但配置存在潜在风险。
证据：服务 MySQL80 正在运行，端口 3306 正在监听，SELECT VERSION() 成功；但 my.ini 指向的 datadir 与服务 BinaryPath 推断的 datadir 不一致。
建议：暂不修复。请先确认当前实际使用实例，再导出诊断报告。
四、涉及修复必须极度谨慎
凡是涉及以下操作，一律视为 Critical 高危操作：
- Data 目录移动。
- Data 目录复制。
- Data 目录覆盖。
- 系统库补回。
mysql 系统 schema 修复。- 初始化 Data。
- 重建服务。
- 删除服务。
- 注册服务。
- 修改 my.ini。
- 修改 datadir。
- 停止正在运行的 MySQL 服务。
- 启动修复后的 MySQL 服务。
五、强制备份要求
执行任何修复计划前必须先备份。
备份范围至少包括：
- my.ini。
- 服务注册信息导出或记录。
- basedir 路径信息。
- datadir 整体快照或可恢复复制。
- 业务库目录。
mysql 系统库目录。performance_schema、sys，如存在。- ibdata1。
- ib_logfile*。
- undo / redo 相关文件，如存在。
- auto.cnf。
- 错误日志。
备份要求：
1. 备份必须在修复前完成。
2. 备份失败不得继续修复。
3. 备份目录必须展示给用户。
4. 备份结果必须写入报告。
5. 修复计划必须引用备份 ID。
6. 不允许用户跳过备份直接修复。
六、三次确认要求
任何 Critical 修复执行前必须三次确认：
第一次确认：风险说明
显示：
该操作涉及 MySQL Data 目录或服务配置，可能导致数据库无法启动、业务库不可访问或数据恢复困难。
第二次确认：备份确认
必须展示备份状态，并要求用户勾选：
我已确认 DevEnv Manager 已完成 Data / my.ini / 服务信息备份，并知道备份目录位置。
如果备份未完成或校验失败，按钮禁用。
第三次确认：强制知晓风险
必须要求用户手动勾选并输入确认文字：
不允许只点一次按钮就执行修复。
七、默认行为必须保守
默认只做：
- 只读诊断。
- 导出报告。
- 解释风险。
- 建议备份。
- 标记“暂不建议自动修复”。
以下场景默认不自动修复：
- MySQL 当前能正常连接。
- 存在多个 MySQL 实例且无法确认当前实例。
- Docker / WSL / phpStudy / XAMPP / Laragon / MariaDB 布局。
- 权限不足无法确认系统库状态。
- 静态检查异常但连接验证正常。
- 用户没有完成备份。
八、疑似误报处理
如果出现：
文件系统检查疑似异常，但服务运行正常，端口监听正常，连接验证正常，SHOW DATABASES 正常。
应显示：
当前 MySQL 实例可用。此前“系统库缺失或不完整”可能来自静态路径检查、权限不足或检测到了非当前实例。建议暂不执行修复，可导出诊断报告进一步确认。
并将结论标记为：
FalsePositiveSuspected 或 UsableWithWarnings
九、文档更新
更新：
docs/troubleshooting.mddocs/user-guide.mddocs/release-v1.5.2.mddocs/issues-57-67.md- 如有必要，更新
docs/software-copyright/ 中数据库修复相关描述，强调默认只读诊断、备份和确认。
文档必须解释：
- 什么是 MySQL 系统库。
- 为什么软件可能判断系统库异常。
- 为什么 MySQL 仍然可能能正常使用。
- 如何判断是真问题还是误报。
- 为什么修复前必须备份。
- 为什么本程序不默认自动修复正在可用的 MySQL。
十、测试要求
新增测试或 mock 场景：
- MySQL 服务运行正常，连接验证成功，但静态路径检查缺少某目录 → 标记为疑似误报或可用但有警告，不直接标 broken。
- datadir 缺少 mysql 系统库，且服务无法启动 → 标记 LikelyBroken。
- 权限不足读取 datadir → 标记 PermissionUnknown，不得误报系统库缺失。
- 多个 MySQL 实例 → 标记 MultipleInstancesAmbiguous。
- Docker / WSL / XAMPP / phpStudy / Laragon 布局 → 标记 UnsupportedLayout 或特殊说明。
- 备份失败 → 修复按钮禁用。
- 未完成三次确认 → 不执行修复。
- 用户未输入确认文字 → 不执行修复。
- 静态异常但连接正常 → 不默认生成高危修复计划。
十一、验收标准
- MySQL 修复中心不再只给“系统库缺失或不完整”的黑箱结论。
- 每个异常结论都有证据、可信度和下一步建议。
- MySQL 正常可用时不会被激进标记为严重故障。
- 疑似误报能被识别和解释。
- 高危修复前必须完成备份。
- 备份失败不得继续修复。
- 高危修复必须三次确认，其中一次强制勾选并输入风险确认文字。
- 不读取业务表内容，不保存数据库密码。
cargo test --all-targets 通过。npm run build 通过。- release notes 记录该诊断可信度和安全修复。
用户反馈现象
用户在 MySQL 修复中心看到类似提示：
但用户实际使用 MySQL 没有明显问题，因此产生疑问：
问题判断
这是 MySQL 修复中心诊断理由不透明 / 健康判定可能过度激进 / 疑似误报 / 高危修复确认不足 的问题。
MySQL 能正常使用，并不一定代表 Data 目录完全健康；但如果软件只看文件夹或某些系统库目录，就直接提示“系统库缺失或不完整”，也可能误导用户。
因此本 issue 的核心目标不是新增 MySQL 修复功能，而是让诊断更可信、更保守、更可恢复：
可能原因分析
软件可能因为以下证据之一判断异常：
mysql系统库目录。mysql系统库目录存在但关键文件缺失。performance_schema/sys/mysql等系统 schema 不完整。影响范围
该问题可能影响：
修复目标
MySQL 修复中心必须从“结论式提示”改为“证据式诊断”。
不要直接显示：
应改为：
一、诊断必须分层
MySQL 诊断至少分为三层：
1. 文件系统静态检查
检查：
mysql、performance_schema、sys等目录。但文件系统检查只能得出“疑似风险”，不能单独得出“数据库不可用”。
2. 服务与进程检查
检查：
3. 连接验证，可选但强烈建议
如果用户提供连接信息或允许使用本机免密/当前配置验证，应检查：
SELECT VERSION()。SHOW DATABASES。mysql、performance_schema、sys。注意：
二、诊断结论必须分级
新增或统一 MySQL 健康结论：
三、UI 必须展示诊断证据
MySQL 修复中心每个候选项必须展示：
示例：
四、涉及修复必须极度谨慎
凡是涉及以下操作，一律视为 Critical 高危操作：
mysql系统 schema 修复。五、强制备份要求
执行任何修复计划前必须先备份。
备份范围至少包括：
mysql系统库目录。performance_schema、sys，如存在。备份要求：
六、三次确认要求
任何 Critical 修复执行前必须三次确认：
第一次确认：风险说明
显示：
第二次确认：备份确认
必须展示备份状态，并要求用户勾选：
如果备份未完成或校验失败，按钮禁用。
第三次确认：强制知晓风险
必须要求用户手动勾选并输入确认文字：
不允许只点一次按钮就执行修复。
七、默认行为必须保守
默认只做：
以下场景默认不自动修复：
八、疑似误报处理
如果出现：
应显示：
并将结论标记为：
九、文档更新
更新：
docs/troubleshooting.mddocs/user-guide.mddocs/release-v1.5.2.mddocs/issues-57-67.mddocs/software-copyright/中数据库修复相关描述，强调默认只读诊断、备份和确认。文档必须解释：
十、测试要求
新增测试或 mock 场景：
十一、验收标准
cargo test --all-targets通过。npm run build通过。