ACL性能瓶颈源于每文件独立条目与频繁链表查询的叠加效应；应优先设父目录默认ACL、控条目≤10、用组替代用户、定期清理冗余，并依存储类型选ext4/XFS，必要时以setgid+umask替代。
ACL 本身不会直接导致海量小文件目录性能下降，真正拖慢的是“每文件都存独立 ACL 条目”+“每次访问都查 ACL 链表”的叠加效应。关键不在“用不用 ACL”，而在“怎么用、用在哪、用多细”。
优先在父目录设默认 ACL，而非逐个文件配置
对含数万小文件的目录（如日志归档、用户上传池），绝不要用 setfacl -R 给每个文件打 ACL。这会把 ACL 元数据塞满 inode，显著增加磁盘 I/O 和内存开销。
- 只对顶层目录设置默认 ACL：
setfacl -d -m g:analysts:r-x /data/reports - 新创建的子目录自动继承 default 规则，并具备继续向下传递能力；新文件只继承权限位（不存 ACL 条目）
- 已有文件权限统一用基础权限（
chmod）或批量 ACL（setfacl -R仅执行一次初始化）处理，之后靠默认 ACL 自动覆盖新增项
限制 ACL 条目数量，避免“一人一条”式滥用
Linux 的 mask 机制会为每个 ACL 条目维护一个有效权限上限，条目越多，内核计算 mask 的开销越大。生产环境建议单个文件/目录 ACL 条目总数控制在 10 条以内。
- 用组代替用户：给
g:devs授权，而不是u:alice、u:bob、u:charlie各设一条 - 定期清理冗余条目：
getfacl /path | grep "^user:" | wc -l快速统计用户级条目数；用setfacl -x u:olduser /path删除已离职人员条目 - 避免混用 allow/deny：Linux ACL 不支持 deny 条目，所谓“拒绝”只能靠不授权+基础权限兜底，无需额外条目
确认文件系统挂载参数与硬件适配
ext4 默认启用 ACL，但若挂载时用了 noatime,nodiratime,barrier=0 等优化选项，可能削弱元数据写入一致性，间接放大 ACL 更新延迟。
- 检查是否真启用了 ACL：
findmnt -n -o OPTIONS /data | grep -q acl，没输出说明未生效，ACL 命令会静默失败 - 对 SSD/NVMe 存储，可保留
journal=ordered（默认），避免关闭日志导致 ACL 元数据损坏 - 机械硬盘或高并发小文件场景，考虑将 ACL 密集型目录单独挂载到 XFS 文件系统——XFS 对大量扩展属性（包括 ACL）的索引效率优于 ext4
用 setgid + umask 替代部分 ACL 场景
很多“让某组人能协作编辑”的需求，其实不需要 ACL。用传统权限组合更轻量：
-
chmod g+s /shared/proj：确保新建文件属组自动继承父目录 -
umask 002（用户登录 shell 中设置）：让新建文件默认带组写权限（-rw-rw-r--） - 再配合
chgrp devs /shared/proj，整个协作流不依赖任何 ACL 条目，零元数据开销
