Symfony 2.4.1安全组件核心是firewall，其pattern为Ant风格前缀匹配，需避免重叠；form_login的login_path和check_path须在firewall范围外，且check_path路由必须为POST；User类须完整实现UserInterface，密码哈希须预存而非动态计算；provider与encoder配置必须准确对应。
Symfony 2.4.1 的安全组件虽较新版本简略，但核心机制已成型：防火墙（firewall）是认证入口的守门人，不是靠写控制器逻辑触发登录，而是由 security.yml 中的 firewalls 配置决定“谁在什么路径下被拦截、如何验证”。配置错一个关键点，就可能表现为无限重定向、404、或始终提示“Invalid credentials”。
firewall 的 pattern 和路径匹配必须精准
每个 firewall 都通过 pattern 定义作用范围。它不是正则，而是前缀匹配（Symfony 2.4 使用 Ant-style 路径模式）。例如：
-
pattern: ^/admin→ 匹配/admin、/admin/、/admin/users，但不匹配/administration -
pattern: ^/login→ 若你把登录表单放在/user/login，这个 firewall 就完全不生效
常见陷阱：多个 firewall 的 pattern 重叠时，Symfony 按定义顺序取第一个匹配项——后定义的即使更精确也不会被选中。
form_login 的 login_path 和 check_path 必须“免检”
使用表单登录时，login_path（显示登录页的 URL）和 check_path（表单 POST 提交的目标）**不能落在当前 firewall 的 pattern 范围内**，否则会因未认证而被循环重定向回登录页。
- 正确示例：
pattern: ^/secured，则login_path: /login、check_path: /login_check应独立于/secured前缀 - 必须确保路由存在且方法匹配：
check_path对应路由需声明为POST；若用routing.yml定义，要加methods: [POST] - 切勿在
check_path对应控制器里加is_granted()或其他认证检查——它本身就是认证起点
User 类必须严格实现 UserInterface
Symfony 2.4.1 不支持 PasswordAuthenticatedUserInterface（那是 5.3+ 才引入），必须手动实现全部接口方法：
-
getUsername()→ 返回唯一标识（如 email 或 username） -
getPassword()→ 必须返回数据库中已哈希的密码字符串（明文或 null 直接导致认证失败） -
getSalt()→ 若用 bcrypt 可返回null；若用 legacysha512则需返回对应盐值 -
getRoles()→ 必须返回非空字符串数组，如array('ROLE_USER')；返回array()或null会导致认证成功但立即被拒绝访问 -
isAccountNonExpired()、isCredentialsNonExpired()等可直接return true，除非你有明确过期逻辑
密码哈希应在用户创建/更新时完成（如在 Doctrine prePersist/preUpdate 回调中调用 $encoder->encodePassword()），而非在 __construct() 或 getter 中动态计算。
provider 和 encoder 需显式声明且匹配
在 security.yml 中：
-
provider必须指向一个已定义的用户提供者（如in_memory、entity或自定义类），否则启动报错：The user provider "xxx" does not exist -
encoder必须与密码哈希方式一致：bcrypt、sha512或plaintext（仅开发用）；若数据库存的是 bcrypt 哈希，但 encoder 写成sha512，认证必失败 - 使用
entityprovider 时，class必须是完整命名空间（如Acme\UserBundle\Entity\User），且该类必须有可被 Doctrine 映射的username和password字段
