SVN authz.conf因BOM或隐形字符解析失败，本质是配置校验中断而非死锁。需用十六进制工具检测EF BB BF、启用“显示所有字符”清除全角空格/零宽空格、保存为UTF-8无BOM，并用svnauthz-validate验证语法及行号错误。
SVN服务端 authz.conf 文件因含隐形特殊字符（比如 UTF-8 BOM、不可见控制符、多余空格或换行）导致服务启动失败、库打不开、报错 Invalid authz configuration，本质不是“死锁”，而是配置解析失败——SVN 读取时直接拒绝加载，表现为权限系统失效、HTTP 500 或命令行提示语法错误。
这类问题常被误认为“死锁”，实际是服务端配置校验中断，需从编码与语法两个层面修复。
确认是否为 BOM 或编码问题
Windows 记事本、旧版编辑器保存的 UTF-8 文件默认带 BOM（EF BB BF），而 SVN 严格要求 无 BOM 的 UTF-8。哪怕只有一处中文路径或注释，BOM 就会导致整个文件解析失败。
- 用十六进制编辑器（如 HxD、Notepad++ 的“编码→转为 UTF-8 无 BOM”）打开
authz.conf，检查开头是否有EF BB BF - Linux 下可用命令快速检测：
head -c 3 authz.conf | xxd，若输出0000000: efbbbf即存在 BOM - 临时改用 ASCII 编码保存（仅含英文和基本符号）测试：若此时 SVN 正常，基本可锁定为编码问题
清除隐形字符并规范格式
BOM 只是常见元凶，还有几类隐形字符也易引发解析失败：
- 全角空格、不间断空格（ ）、零宽空格（U+200B）：复制粘贴中文文档或网页内容时极易混入，肉眼不可见但破坏等号对齐
- Windows 回车（CRLF）混用 LF：虽多数情况兼容，但某些 SVN 版本（尤其搭配 Apache + mod_dav_svn）对行尾敏感
- 注释行以中文标点结尾（如“# 权限说明。”）：部分老版本 svnserve 对句末中文标点后换行处理异常
建议操作：
- 用 VS Code / Notepad++ / UltraEdit 打开，启用“显示所有字符”（¶ 或 ␍ ␊），逐行检查异常符号
- 删除全部注释，只保留最小有效配置（如
[groups]和[/]区块），确认能否加载；再逐步加回内容定位问题行 - 统一使用 Unix 换行（LF），保存为 UTF-8 无 BOM
验证语法与路径合法性
即使编码干净，以下写法也会触发 Invalid authz configuration：
- 权限行缺少等号：
@dev r❌ 应为@dev = r✅ - 路径含非法字符或未转义：如
[my/project/v1.0]中的.和/本身合法，但若写成[my\project]（反斜杠）则无效 - 用户组名含空格或特殊符号却未加引号：
[groups] front end = u1,u2❌ 应写为front_end = u1,u2或"front end" = u1,u2 - 重复定义同一路径区块，或区块名拼写不一致（如
[/trunk]与[trunk]被视为不同路径）
推荐用官方工具验证：
- SVN 自带校验命令（需安装完整版）：
svnlook authz /path/to/repo --file /path/to/authz.conf，会输出具体错误行号 - 在线 authz 校验器（如开源的
svn-authz-validator工具）可快速反馈语法位置
重启服务并观察日志
修改后不能直接生效，必须：
- 如果是 svnserve 独立服务：先
killall svnserve或查 PID 后kill -9，再重新启动 - 如果是 Apache + mod_dav_svn：执行
sudo apachectl graceful或systemctl reload apache2 - 立即查看服务日志：
tail -f /var/log/apache2/error.log或svnserve --daemon --log-file=/var/log/svn.log对应日志路径 - 日志中若出现
authz_parse error at line X，即对应你刚改的那行，精准定位问题
