auth-constraint不生效的主因是security-constraint路径匹配错误；其次为容器角色未映射、login-config缺失、schema版本不兼容或框架接管导致xml配置被绕过。
web.xml 里 auth-constraint 不生效？先看 security-constraint 是否覆盖了正确路径
很多情况不是角色配置错了，而是 url-pattern 写得过于宽泛或过于狭窄。比如写成 /admin/* 却实际访问的是 /admin/dashboard.jsp（没问题），但若写成 /admin 就不会匹配任何带后缀的请求。
-
url-pattern必须和实际请求路径完全匹配（按 Servlet 规范的映射规则），不支持正则，只认*和精确路径 - 多个
security-constraint块会叠加生效，但只要有一个没配auth-constraint，对应路径就可能被“漏放” - 静态资源（如
.js、.css）如果被某个security-constraint拦截又没配auth-constraint，会导致 403 或 401 异常
role-name 在 auth-constraint 里写了，但登录后仍 403？检查容器角色映射
Tomcat、Jetty 等容器默认不自动把用户账号和 web.xml 里的 role-name 关联起来——你写了 <role-name>admin</role-name>，不代表用户登录时就自动拥有了这个角色。
- Tomcat 需在
conf/tomcat-users.xml中显式声明<role rolename="admin"></role>，再给用户分配该角色 - 使用 JDBCRealm 或 JNDIRealm 时，数据库/目录服务返回的角色名必须与
auth-constraint中的role-name完全一致（大小写敏感） - Spring Security 或 Shiro 等框架接管认证后，
web.xml的auth-constraint会被绕过，此时它只是摆设
用了 auth-constraint 却没跳转到登录页？确认 login-config 配置完整
auth-constraint 只负责“谁可以访问”，不负责“怎么登录”。缺了 login-config，容器不知道该重定向到哪，往往直接返回 401 或空白响应。
- 必须配
<auth-method>FORM</auth-method>才能走表单登录；用BASIC则弹系统级对话框 -
<form-login-page></form-login-page>路径必须是应用内可匿名访问的页面（不能受其他security-constraint保护） -
<form-error-page></form-error-page>如果路径配置错误或返回非 200，会导致登录失败时出现 404 或无限重定向
部署后权限突然失效？注意 web.xml 的 schema 版本和容器兼容性
Servlet 3.0+ 容器（如 Tomcat 7+）对 web.xml 的 schema 版本很敏感。用老版本 schema 声明却写了新语法，或反过来，都会让安全约束静默失效。
- Servlet 3.0 对应的
web-app声明要包含version="3.0"和正确的命名空间，否则auth-constraint可能被忽略 - 某些 IDE 自动生成的
web.xml默认用 2.5 schema，而项目依赖了 3.x 的 API，这时需手动更新根元素声明 - WebSphere、WebLogic 等商业容器对
role-link和security-role-ref更严格，本地测试 OK 不代表上线一定 OK
真正麻烦的从来不是写几行 XML，而是路径匹配的隐式行为、容器角色加载时机、以及和实际登录机制之间的衔接断点。这些地方一不留神，日志里连报错都没有，只有反复 403。
