AppArmor的complain与enforce模式是同一profile的两种运行状态，complain仅记录违规行为并放行，enforce则拒绝违规操作并记日志；切换必须用aa-complain/aa-enforce或apparmor_parser -C/-E命令，不可靠注释修改，且需aa-status验证生效。
AppArmor 的 complain 和 enforce 模式本质是同一份 profile 的两种运行状态，切换不修改配置文件内容，只改变内核对违规行为的响应方式。
模式差异直接决定安全效果
complain 模式下，AppArmor 只记录违反规则的操作（比如进程试图写某个被禁止的文件），但放行；enforce 模式下，相同操作会被立即拒绝，并记入日志。前者适合调试 profile 是否覆盖全面，后者才是真实防护状态。
切换命令不能靠改注释，必须用专用工具
profile 文件里的注释（如# Profile in complain mode）不影响实际模式。真正生效的是内核中加载后的状态，需用以下命令操作：
-
设为 complain 模式：
sudo aa-complain /etc/apparmor.d/usr.bin.nginx（路径必须与 profile 文件名一致） -
设为 enforce 模式：
sudo aa-enforce /etc/apparmor.d/usr.bin.nginx - 也可用
apparmor_parser -C或-E直接重载并指定模式，例如：sudo apparmor_parser -C /etc/apparmor.d/usr.bin.nginx
切换后要验证是否真生效
仅执行命令不代表成功，需确认两点：
- 运行
aa-status，查看目标进程是否出现在 “profiles in enforce mode” 或 “profiles in complain mode” 区域 - 检查
/var/log/syslog或journalctl -t kernel | grep apparmor，enforce 模式下应有AVC DENIED日志，complain 模式下只有AVC ALLOWED（即本该拒绝但放行了）
常见误操作导致切换失败
不是所有 profile 都能任意切换——前提是它已被成功加载到内核。如果 aa-status 根本不显示该 profile，说明：
- profile 文件名未严格匹配二进制路径（如守护进程实际运行在
/usr/local/bin/myapp，但 profile 命名为/etc/apparmor.d/myapp） - profile 存在语法错误（引号不闭合、deny 规则写在 allow 前等），导致
apparmor_parser -r加载失败 - 目标服务未重启，旧进程仍运行在无 profile 状态，新 profile 不会自动绑定
