开启OPcache是PHP 7.4+最简单有效的提速操作，可降低响应时间30%–50%，需显式配置opcache.enable=1等关键项并确认phpinfo中Opcode Caching为Enabled。
PHP 7.4+ 开启 OPcache 是最简单有效的提速操作
不启用 OPcache，PHP 每次请求都要重新解析、编译脚本，相当于每次打开网页都重读一遍源码。开启后，字节码被缓存到共享内存，跳过重复编译，实测响应时间常降低 30%–50%。
常见错误现象：opcache.enable=0 在 php.ini 中被注释或设为 0；或者 CLI 模式下 OPcache 默认关闭，但 Web 服务器（如 Apache/FPM）未单独配置。
- 确认生效：访问
phpinfo()页面，搜索opcache，看到Opcode Caching => Enabled才算成功 - 关键配置项必须显式设置（仅靠默认值不够）：
opcache.enable=1、opcache.memory_consumption=128、opcache.max_accelerated_files=10000、opcache.validate_timestamps=0（生产环境关掉自动检测，上线后需手动opcache_reset()） - FPM 场景下，
opcache.revalidate_freq对 CLI 无效，别在php -v后误判配置是否生效
用 array_key_exists() 还是 isset() 判断数组键？
两者行为不同，选错会引发逻辑错误或性能浪费。isset() 快但不处理 null 值；array_key_exists() 准确但慢约 2–3 倍（尤其大数组）。
使用场景：$_GET['id'] 是否传了且非空？用 isset($_GET['id'])；是否“明确声明过这个键”（哪怕值是 null）？才用 array_key_exists('id', $_GET)。
立即学习“PHP免费学习笔记（深入）”；
-
isset($arr['key'])返回false如果$arr['key'] === null，但它不触发__isset()魔术方法 -
array_key_exists('key', $arr)返回true即使$arr['key'] === null，且对对象调用会触发__isset() - 循环中高频判断（如 API 参数校验），优先用
isset()+ 显式!== null组合，避免无谓开销
MySQL 查询慢，mysqli_query() 和 PDO::query() 有性能差别吗？
没有本质差别。底层都是调用 MySQL C API，瓶颈在 SQL 本身、索引、网络延迟，而非 PHP 扩展封装层。盲目换 PDO 不会提速，反而可能因默认关闭预处理而引入安全风险。
容易踩的坑：用 PDO::query() 拼接变量进 SQL 字符串，导致 SQL 注入；或用 mysqli_query() 执行大量小查询却不复用连接。
- 真正影响性能的是连接复用：
mysqli要显式传MYSQLI_CLIENT_FOUND_ROWS等标志，PDO需设PDO::ATTR_PERSISTENT => true（注意 FPM 下持久连接可能引发状态污染） - 查单条记录别用
SELECT *，用SELECT id, name减少网络传输和 PHP 数组构建开销 -
mysqli_fetch_all(MYSQLI_ASSOC)比逐行fetch_assoc()内存占用高，大数据集优先流式处理
Composer 自动加载变慢，composer dump-autoload --optimize 还管用吗？
在 PHP 7.4+ + OPcache 全开的前提下，--optimize（即生成 classmap）收益极小，甚至可能因 classmap 文件过大拖慢首次加载。现代项目更应依赖 PSR-4 自动加载 + OPcache 的文件级缓存。
典型错误：上线前机械执行 composer dump-autoload --optimize --no-dev，却忽略 vendor/autoload.php 本身是否被 OPcache 缓存（它默认不在 opcache.blacklist 里，但某些部署脚本会误加）。
- 检查
opcache.is_enabled和opcache.file_cache_only是否冲突（后者禁用共享内存缓存，会使 classmap 失效） - PSR-4 映射比 classmap 更易维护，且 Composer 2.x 默认启用
--apcu加速映射查找（需 APCu 扩展） - 若真要 classmap（如闭包函数需提前注册），务必配合
--classmap-authoritative，否则运行时仍会 fallback 到文件扫描
OPcache 配置不是一劳永逸的，opcache.max_accelerated_files 填太小会导致缓存碰撞，填太大又浪费内存；classmap 和 PSR-4 的取舍得看实际文件数量和部署流程——这些细节没监控数据撑着，光靠“应该更快”去调，很容易南辕北辙。
