避免重复计算与函数调用
刚接触PHP时最容易犯的错误就是在循环里做重复计算。比如计算字符串长度，每次循环都调用strlen()函数，这就像每次喝水都要重新烧一壶水一样浪费资源。聪明的做法是把计算结果存到变量里复用。
函数调用也是有成本的。我见过有人把同一个数据库查询函数放在循环里调用，结果页面加载慢得像蜗牛爬。这种时候应该把查询结果先取出来存到数组里，循环时直接使用数组数据。
合理使用数据类型与数据结构
PHP的数组功能很强大，但不是什么数据都适合用数组。存储简单的键值对时，数组确实很方便；但如果要处理复杂对象关系，适当使用对象可能更清晰高效。
选择数据结构就像选工具，用螺丝刀拧螺丝很顺手，但拿来敲钉子就有点勉强了。比如要快速查找数据，用哈希表就比线性数组高效得多。记住：合适的数据结构能让代码跑得更快，就像穿上合脚的鞋子走路更轻松。
减少不必要的文件包含
require和include用起来很方便，但滥用它们就像往背包里塞太多东西——会让程序变慢。特别是把相同的库文件在多个地方重复包含，这就像把同一本书买了好几本放在家里不同位置，既浪费钱又占地方。
我建议把常用的库文件集中管理，用自动加载机制按需加载。这样既避免了重复包含，又能确保用到的类都能正确加载。就像整理衣柜，把常穿的衣服放在容易拿到的地方，不常用的收起来。
及时释放变量与内存管理
PHP有垃圾回收机制，但这不意味着我们可以随意创建变量不管不顾。大数组用完就unset掉，就像吃完饭要收拾餐桌一样是个好习惯。特别是处理大文件或大量数据时，及时释放内存能让程序跑得更顺畅。
全局变量就像公共区域的物品，谁都能用但也容易被滥用。尽量限制变量的作用范围，该用局部变量时就用局部变量。想象一下如果家里所有东西都放在客厅会多混乱，程序里的变量作用域也是同样的道理。
使用OPcache加速PHP执行
每次PHP脚本执行都要经历解析、编译的过程，这就像每次做饭都要重新学习菜谱一样浪费时间。OPcache把编译后的脚本缓存起来，下次直接使用，效果立竿见影。开启OPcache后，我的网站响应速度提升了近40%，简直像给PHP装上了涡轮增压器。
配置OPcache时要注意内存分配，太小会导致缓存命中率低，太大又浪费资源。就像给手机买存储卡，128GB可能不够用，但买1TB又太奢侈。找到合适的平衡点很关键，通常16MB到64MB对中小型项目就够用了。
应用级缓存（Redis/Memcached）
数据库查询往往是性能瓶颈，特别是那些变化不频繁的数据。Redis和Memcached就像给数据库加了个"备忘录"，把常用数据存在内存里快速读取。我最近给一个电商网站加了Redis缓存，商品列表的加载时间从2秒降到了200毫秒，用户都夸网站变"丝滑"了。
选择缓存方案时，Redis功能更丰富但内存占用稍高，Memcached更轻量但功能简单。就像选手机，要功能全面选iPhone，追求性价比可以选安卓。根据项目需求选择最合适的工具才是明智之举。
静态资源托管与CDN加速
图片、CSS、JS这些静态文件占用了网页加载的大部分时间。把它们从主服务器分离出来，就像把仓库里的货物分散到各个配送中心，用户访问时能就近获取。我试过把静态资源放到CDN上，东京的用户不再需要从纽约服务器下载文件，加载速度提升了3倍多。
配置CDN时要注意缓存策略，设置太短起不到加速效果，太长又可能导致更新不及时。就像牛奶的保质期，7天太短容易浪费，30天又怕变质。通常静态资源可以设置较长的缓存时间，配合版本号控制更新。
代码分割与懒加载技术
把整个应用的JS打包成一个巨型文件，就像把整个衣柜的衣服都穿在身上出门。现代前端开发提倡按需加载，把代码拆分成多个小块，用户访问哪个功能再加载对应的代码。我在一个管理后台项目中实践了懒加载，首屏加载时间从4秒降到了1.5秒，老板看我的眼神都变得和善了。
实现懒加载要注意模块划分的粒度，太细会增加请求次数，太粗又失去优化意义。就像切蛋糕，每人一小块刚好，切成碎末就不好拿了。通常按功能模块划分比较合理，保持每个模块在50-300KB左右。
索引的合理使用
数据库没有索引就像在图书馆找书没有目录，只能一本本翻查。给常用查询字段加索引后，查询速度能提升几十倍。但索引不是越多越好，就像给书贴太多标签反而更难找。我遇到过一张表建了15个索引，结果写入速度慢得像蜗牛。通常选择WHERE、JOIN、ORDER BY这些高频操作的字段建索引就够了。
复合索引的顺序也很讲究，就像手机通讯录先按姓氏再按名字排序才合理。把选择性高的字段放前面，让数据库能更快缩小查找范围。记住每个额外索引都会占用空间并影响写入性能，需要权衡利弊。
批量操作与查询优化
每次数据库操作都有网络开销，就像去超市买10样东西分10次结账。批量插入100条数据用一条INSERT语句比100条单独的INSERT快得多。我在处理用户导入功能时，把逐条插入改成批量操作，执行时间从2分钟缩短到5秒。
查询语句也要避免N+1问题，就是先查主表再循环查关联表。这就像查班级学生名单，却要挨个敲门问每个学生的家庭住址。使用JOIN或子查询一次性获取所需数据，能减少90%以上的查询次数。EXPLAIN命令是我的好朋友，经常用它分析查询执行计划找出优化点。
避免复杂JOIN操作
JOIN操作就像同时处理多张Excel表格，表越多性能下降越厉害。五张表JOIN查询可能会让数据库引擎抓狂。有时候拆分成多个简单查询在代码里组装数据反而更快，就像分开处理各个部门报表再汇总。特别是当JOIN的表都有大量数据时，这种优化效果更明显。
冗余部分数据也是解决JOIN性能问题的妙招。比如在订单表里直接存用户姓名，虽然不符合范式理论，但能避免每次查订单都要JOIN用户表。这就像把常用联系人存在手机里，不用每次都去通讯录查找。当然要权衡数据一致性和查询性能的关系。
分页显示与缓存技术
不分页查询大数据量就像试图一口吃掉整个披萨。LIMIT分页在数据量大时也会变慢，特别是偏移量很大时。我发现用WHERE id > last_id替代LIMIT offset能显著提升性能，就像看书记下页码而不是从头数行数。
热门数据更应该缓存起来，把数据库想象成慢速硬盘，缓存就是内存。我做过一个新闻网站，把首页文章列表缓存10分钟，数据库压力直接降了80%。缓存失效策略要设计好，就像牛奶要定期检查保质期。对于实时性要求高的数据可以设置短缓存时间，或者用主动更新机制。
异步处理与任务队列
你有没有遇到过用户提交表单后，后台要处理半小时才能完成的情况？这种同步处理方式就像让顾客在收银台等着厨师现杀活鱼。把耗时任务扔进消息队列异步处理，用户立刻就能得到响应。我用Redis实现过邮件发送队列，主程序只需要把任务放进队列就返回，后台Worker慢慢处理，系统吞吐量直接翻倍。
RabbitMQ和Beanstalkd都是不错的队列选择，就像不同品牌的快递公司。关键是要确保任务最终会被执行，就像快递要有签收确认。设置失败重试机制和死信队列很重要，我见过因为一个失败任务阻塞整个队列的情况，那场面就像快递站爆仓。
使用Swoole协程框架
传统PHP每个请求都要重新初始化，就像每次点菜都要重新招厨师。Swoole让PHP变身常驻内存服务，处理请求快得像快餐店。我重构过一个API服务，从Apache换成Swoole后，QPS从200飙升到5000+，效果堪比给自行车装上火箭推进器。
协程是Swoole的杀手锏，能同时处理上万个连接。想象服务员可以同时服务多桌客人，而不是等一桌点完才去下一桌。但要注意共享资源竞争问题，我在使用全局变量时踩过坑，就像多个服务员同时往一个盘子里装菜会打架。使用Channel做协程间通信更安全。
内置函数优先原则
PHP开发组的大佬们写的内置函数，通常比我们自己写的快得多。就像专业厨师做的蛋炒饭，肯定比我这个业余选手强。str_replace()比用循环实现的字符串替换快10倍不止，array系列函数也都是经过极致优化的。
但要注意有些函数的内存消耗，比如file_get_contents()读取大文件会吃光内存。我有次用这个函数读500MB日志文件，直接把服务器搞崩了。换成fopen()逐行读取就稳如老狗，就像小口吃饭不容易噎着。
正则表达式使用规范
正则表达式就像瑞士军刀，功能强大但用不好会伤到自己。简单的字符串操作能用strpos就别用preg_match，后者要启动整个正则引擎，就像用核弹打蚊子。我做过测试，用strpos检查字符串包含比正则快20倍。
写正则要避免灾难性回溯，糟糕的正则能让服务器CPU飙到100%。曾经有个/(a+)+b/的表达式匹配失败时会把服务器拖死，就像陷入无限迷宫。使用原子组和 possessive量词能避免这个问题，实在不行就设置超时限制。
性能分析工具（Xdebug/Blackfire）
写完代码就万事大吉了？那可不行，就像开车不看仪表盘迟早要出事。Xdebug是我的第一选择，它能生成详细的函数调用报告，告诉你哪些代码在偷偷吃掉CPU时间。有次我发现一个看似简单的页面加载要3秒，用Xdebug一查，原来是个不起眼的循环跑了2000次。
Blackfire更像个性能X光机，能直观显示每行代码的资源消耗。我用它优化过一个电商网站，发现商品图片处理占用了70%的响应时间。换成异步处理后，页面加载时间从2秒降到300毫秒，效果比喝红牛还提神。
代码审查与重构技巧
代码审查不是找茬大会，而是集体智慧的碰撞。我们团队每周都有代码走查，就像定期体检。有次同事指出我写的SQL查询没用索引，修改后查询时间从1.2秒降到0.02秒，这差距比蜗牛和火箭还大。
重构要像园丁修剪枝叶，不能一剪刀把树砍秃了。我习惯用"小步快跑"的方式，每次只改一个小点然后立即测试。曾经大刀阔斧重构用户模块，结果引发连环bug，那场面就像推倒多米诺骨牌。现在学乖了，改一点测一点，稳扎稳打。
基准测试与优化验证
优化前后不测试？那跟蒙眼开车没区别。我用ApacheBench做压力测试，看着QPS数字往上涨比看股票涨停还开心。但要注意测试环境要接近生产环境，我有次在本地虚拟机测试效果很好，上线后发现完全不是那么回事，就像用玩具车模拟F1比赛。
优化效果要用数据说话，不能凭感觉。记录下关键指标：响应时间、内存占用、CPU负载。我建了个Excel表格跟踪每次优化的效果，三个月后发现系统吞吐量提升了8倍，这成就感比游戏通关还爽。
持续集成中的性能检查
把性能检查放进CI流程，就像给代码质量装上警报器。我们在GitLabCI里加了PHPStan和性能测试，合并请求前自动跑一遍。有次新人提交的代码导致内存泄漏，CI直接亮红灯拒绝合并，避免了一场线上事故。
性能检查要设置合理的阈值，太严格会频繁误报，太宽松又没意义。我们团队经过多次调整，现在设置的规则是：单个API响应超过500ms或内存占用超过50MB就会触发警告。这就像给运动员设定合理的训练目标，既不能太轻松也不能不切实际。
标签： #PHP代码优化技巧 #PHP性能提升方法 #初学者PHP开发指南 #PHP内存管理策略 #高效PHP编程实践
