svn authz“看似生效却实际失效”的主因是权限越界与路径匹配错位：①单库模式下误用[project1:/trunk]（应为[/trunk]），②多库模式下漏写库名，③路径节引用不存在用户/组导致规则静默跳过，④bom或crlf干扰解析，⑤未设[/]兜底致深层路径无默认权限。
SVN中authz配置“看似生效却实际失效”，常不是语法错误，而是权限越界引发的隐性冲突。用户被赋予了超出其身份范围的路径权限，或路径定义与服务启动方式不匹配，导致规则被跳过、覆盖甚至直接拒绝认证。解决这类问题，关键在于厘清权限作用域与执行顺序。
检查 svnserve 启动参数与路径节的匹配关系
authz 中的路径节（如 [project1:/trunk] 或 [/]）是否生效，取决于 svnserve 是以单库模式还是多库模式运行：
- 若用 svnserve -d -r /data/svn/project1 启动（单库模式），所有路径节必须写成 [/]、[/trunk] 等相对仓库根的形式；写成 [project1:/] 将被完全忽略
- 若用 svnserve -d -r /data/svn 启动（多库模式），则必须明确指定库名，如 [project1:/trunk]；仅写 [/] 表示所有仓库的根路径，容易造成权限泛化或越界
- 客户端访问 URL 必须与路径节逻辑一致：单库模式对应 svn://host/，多库模式对应 svn://host/project1
验证用户/组是否存在且未被重复或遗漏定义
权限越界常源于 authz 中引用了不存在或拼写错误的用户或组，SVN 会静默跳过整段规则，导致后续权限降级为默认值（如 anon-access 或 auth-access 所设）：
SVN搭建及使用教学视频(布尔教育)
下载
《SVN视频教程》，SVN:全称Subversion，是代码版本管理软件，管理着随时间改变的数据。这些数据放置在一个中央资料档案库 (repository) 中。这个档案库很像一个普通的文件服务器,不过它会记住每一次文件的变动。这样你就可以把档案恢复到旧的版本, 或是浏览文件的变动历史。许多人会把版本控制系統想像成某种“时光机器”。
- 确认 [groups] 节中每个组名只出现一次，成员列表无多余空格或换行，例如 dev = alice,bob ✅，而非 dev = alice, bob ❌（逗号后空格可能触发解析失败）
- 检查所有路径节中引用的用户名或 @group 是否在 [users]（passwd 文件）或 [groups] 中真实存在；删除已停用账号时，务必同步清理其在 authz 中的所有权限行
- 使用 svnauthz-validate /path/to/authz 命令主动校验，它能精准定位第几行的语法或引用错误
排查编码与不可见字符干扰
尤其在中文环境或跨平台编辑 authz 文件后，BOM 头、Windows 换行符（CRLF）、全角符号或隐藏控制字符会导致解析中断，表现为“配置无效”但无明确报错：
- 将 authz 文件保存为 UTF-8 无 BOM 格式（UltraEdit、VS Code、Notepad++ 均支持显式设置）
- 避免用记事本直接编辑；推荐用 vi/vim 或 sed -i 's/\r$//' authz 清理 Windows 换行符
- 对含中文路径的仓库，确保路径节中路径名与实际仓库结构完全一致，且 authz 文件本身编码与 SVN 服务读取逻辑兼容（SVN 内部按 UTF-8 解析）
确认权限继承与覆盖逻辑是否符合预期
SVN 权限是路径就近匹配+自上而下继承，但不会自动向下传递；越界常因误以为父目录权限会“覆盖”子目录，实则可能被更具体的规则截断：
- [/] 设为 * = r，再在 [/secret] 设 alice = rw —— 这是安全且有效的
- 但若 [/] 未设任何权限，而只在深层路径如 [/trunk/src] 设权限，则根路径及其它子路径默认无访问权，用户检出失败
- 权限不叠加：用户属于多个组时，取各组在该路径下的最高权限（rw > r > 无），但不会跨路径累加；确保关键路径有显式声明
