ulimit -n 限制是否生效取决于PHP进程启动时继承的系统级资源限制；改/etc/security/limits.conf无效常见原因是PAM未加载pam_limits.so，且systemd服务（如PHP-FPM）需在unit文件中配置LimitNOFILE并重启进程。
PHP 8.2 本身不直接管理文件描述符（fd）数量，ulimit -n 限制是否生效，取决于 PHP 进程启动时继承的系统级资源限制——哪怕用了 JIT 或内存优化，一旦 fd 耗尽，fopen、mysqli_connect、curl_init 全都会失败，报 Too many open files。
为什么改了 /etc/security/limits.conf 却没用？
常见错误是只改了 limits.conf，却漏掉 PAM 加载模块。Ubuntu/Debian 必须确保 /etc/pam.d/common-session 里有这行：
session required pam_limits.so
CentOS/RHEL 则要检查 /etc/pam.d/login 或 /etc/pam.d/system-auth。没有这行，limits.conf 就是注释。
另外，* 在 limits.conf 中不覆盖 systemd 管理的服务进程（比如宝塔里的 PHP-FPM），它只对交互式登录用户或 su - www 这类显式切换有效。
立即学习“PHP免费学习笔记（深入）”；
- 验证方式：用
ps aux | grep php-fpm找一个 worker PID，再执行cat /proc/<pid>/limits | grep "Max open files"</pid> - 如果显示还是 1024，说明 PHP-FPM 没继承新限制，不是配置没写对，而是没被 PAM 加载或没重启进程
PHP-FPM 进程怎么真正拿到 65535？
PHP-FPM 是由 systemd 或 init 启动的守护进程，它不读 limits.conf，必须在服务单元文件里显式声明。宝塔默认没配，得手动补：
编辑 /etc/systemd/system/php-fpm.service.d/override.conf（目录不存在就创建）：
[Service] LimitNOFILE=65535
然后重载并重启：
systemctl daemon-reload systemctl restart php-fpm
注意：systemctl restart 是必须的，reload 只重载配置，不重设资源限制。
- 如果你用的是宝塔面板，PHP-FPM 页面点「重启」按钮，底层就是
systemctl restart，只要 override.conf 存在且生效，就能拿到新值 - 别信「重载配置」——它不会重建进程，也就不会重新申请 fd 限额
max_connections 和 ulimit 怎么配才不冲突？
MySQL 的 max_connections = 500 不是孤立数字。每个连接至少占 2–4 个 fd（socket + 错误日志句柄等），PHP-FPM 每个 worker 还要开文件、curl、临时 socket……所以总 fd 需求 ≈ PHP-FPM max_children × (avg_fd_per_request + 10) + MySQL max_connections × 3 + 系统保留。
假设你设了 php-fpm www.conf 中 pm.max_children = 50，平均每个请求开 8 个 fd，MySQL 设了 300 连接：
粗略估算：50 × 18 + 300 × 3 = 900 + 900 = 1800 → 此时 ulimit -n 65535 完全够用；但若你把 pm.max_children 拉到 200，又开了 Redis + cURL + 日志轮转，fd 很快就破万。
-
ulimit -n建议设为 65535，但前提是内核fs.file-max≥ 131072（否则内核会截断） - 别只盯着 PHP，用
lsof -p <pid> | wc -l</pid>实测单个 PHP-FPM worker 实际开了多少 fd，比拍脑袋估算靠谱
PHP 8.2 自身要不要调 memory_limit？
要，但和 ulimit 是两回事。PHP 8.2 内存碎片优化再好，也救不了 memory_limit = 128M 下跑 200 并发、每个请求加载 3 个大数组的场景。
关键点在于：fd 耗尽是“连接失败”，内存耗尽是“脚本崩溃”，两者常并发出现，但根因不同。
- 先确认瓶颈：看错误日志里是
Too many open files还是Allowed memory size of ... exhausted - 如果是后者，
memory_limit建议按 worker 平均占用 × 1.5 设置，比如实测单请求占 25M，就设memory_limit = 40M，而非盲目拉到 512M - PHP 8.2 的 JIT 对 CPU 密集型有效，但对 I/O 密集型（如大量数据库查询）帮助有限——这时候优化连接复用、减少
new PDO()频次，比调 memory_limit 更治本
真正卡住的从来不是某个参数数字，而是你改完 ulimit 却忘了重启 PHP-FPM，或者调高了 max_connections 却没同步扩 fs.file-max，又或者压测时用 ab -c 1000 但 PHP-FPM 根本没开到 1000 个子进程——这些断层，才是并发一上就崩的真实原因。
