你修改的文件，就是它读取的文件吗？

同一台设备上可能同时保存下载版、手动整理版和客户端导出的配置。编辑器中看起来正确的文件，不一定是当前进程使用的那份。先记录Mihomo可执行文件的完整路径与版本，再查看启动参数中的-f和-d。前者指定配置文件，后者指定配置目录；二者不要混为同一个位置。

为Mihomo指定绝对路径，更容易复现检查。确认文件确实存在、没有被系统隐藏成config.yaml.txt，并且当前账户可读取。配置目录还可能涉及数据文件、缓存与相对资源路径。初次使用的路径关系可参照配置准备与首次运行说明，不要仅凭文件夹名称判断程序实际行为。

在独立目录中执行检查

先查看当前版本的帮助输出，再使用测试开关。下列/path/to/均为示例路径，运行前必须替换；Windows应使用对应的可执行文件和本地路径。将可信配置与依赖资源副本放在独立检查环境，避免与正在运行的实例共享可写数据。

# 示例路径：不会代表任何实际设备的当前配置
mihomo -v
mihomo -h
mihomo -t -d /path/to/check-data -f /path/to/config.yaml

-t让Mihomo测试配置后退出。检查过程可能初始化目录或加载所需资源，因此不能把它描述成对所有环境都完全只读。关注完整错误输出与退出状态，先解决第一个明确的错误，再重新检查；后续提示有时只是前面解析失败造成的连锁结果。

把错误分成三类，逐层处理

文件没有被正确打开

遇到路径不存在或权限拒绝，先核对路径、引号、账户与目录访问权限。终端当前目录改变后，相对路径可能指向另一个位置。以服务启动时，还要检查服务账户与工作目录。不要为了解决读取问题给所有用户开放整个目录。

文件能读取，但格式或内容不被接受

YAML使用缩进表达层级，同级项应对齐，缩进使用空格而非Tab。检查编码、冒号、引号与复制文本时混入的全角字符。字段是否受支持还取决于核心版本，单纯能被通用YAML解析器打开，不代表核心一定接受其含义。保留原文件，每次只调整一组相关内容。

配置依赖的资源无法加载

某些配置还引用本地文件或远端资源。路径错误、资源缺失和加载失败，应与主文件的YAML语法错误分开处理。核对资源位置与访问条件，同时保留完整上下文。如果启动时才出现异常，可按运行日志与监听诊断方法判断所处阶段，而不是反复修改无关字段。

“通过”之后，还有另一层验证

配置验证通过，并不意味着目标端口已经成功监听，也不保证代理节点、域名解析和远端服务可用。文件被修改后，已经运行的Mihomo进程也未必自动重新加载。需要确认实际启用的配置与测试副本一致，再按既有管理方式加载或重启，并观察新的启动输出。

如果问题只在替换内核后出现，保留两套程序与对应配置，通过升级与回退记录比较变化。有效的排查记录至少包含程序版本、脱敏后的命令、配置路径和第一条错误；不要把含凭据的完整配置公开粘贴。