g() 耗内存因其内部静态数组持续累积时间戳和内存快照，高频调用（如循环、嵌套）导致几mb额外开销；应仅在关键路径打点，生产环境禁用，改用 memory_get_usage(true) 手动采样。
用 G() 统计内存时为什么反而更耗内存
G() 是 ThinkPHP 提供的轻量级性能打点工具，但它的实现依赖内部静态数组缓存所有标记点。当你在循环里高频调用 G('start') 或嵌套多次调用（比如模板中、中间件里、模型钩子里都打点），这些时间戳和内存快照会持续累积，尤其在大列表导出或分页接口中，G() 自身可能吃掉几 MB 内存——不是你代码的问题，而是统计行为放大了问题。
实操建议：
- 只在真正需要定位瓶颈的接口顶部和关键分支前后打点，避免在
foreach内部、模板渲染循环里重复调用 - 生产环境务必关闭所有
G()调用，它不参与日志归档，纯属调试辅助 - 若必须长期监控，改用
memory_get_usage(true)手动采样，例如：echo 'mem: ' . (memory_get_usage(true) / 1024) . " KB\n";
Db::select() 拿全量数据是内存杀手
ThinkPHP 默认的 select() 会把整个结果集转成二维数组并加载进 PHP 内存，哪怕只是查 1 万条用户记录，每条含 10 个字段，轻松突破 64MB 限制。这不是数据库慢，是 PHP 进程扛不住。
实操建议：
- 能用
find()就不用select()，单条数据永远比集合安全 - 必须查多条时，优先加
field()限定字段，禁用select('*') - 大数据场景强制走
chunk()：例如Db::table('log')->chunk(500, function($logs) { /* 处理 */ });，它底层用游标+ LIMIT/OFFSET 分批，不累积结果集 - 导出类接口别拼 HTML 表格再返给前端，直接用
fputcsv()流式写文件响应
静态变量和闭包引用导致内存无法释放
TP 的模型、命令、事件监听器里常有人写 private static $cache = []; 或在闭包里捕获大对象（如 use ($bigData)），这些变量生命周期绑定到请求结束，但 PHP 垃圾回收不保证立刻释放——尤其当存在循环引用（比如对象 A 持有 B，B 又通过闭包引用 A）时，unset() 都不一定管用。
实操建议：
- 检查自定义命令类、全局事件回调、中间件构造函数中是否声明了静态数组或长生命周期对象
- 避免在
chunk()回调闭包里use整个查询实例或大数组；改用参数传值或局部重建 - CLI 模式跑队列（如
php think queue:work）时，在循环末尾手动触发回收：gc_collect_cycles(); - 用
memory_get_usage()在关键节点打印，确认哪段代码后内存没回落
debug 开启状态下模板编译和 SQL 日志吃掉 30%+ 峰值内存
ThinkPHP 的 app_debug = true 不只是显示错误页面那么简单：它会全程保留 SQL 执行上下文、开启模板自动编译、缓存未压缩的 trace 信息、记录完整 query log 到内存……这些在开发时很爽，上线后就是定时炸弹。
实操建议：
- 生产环境配置文件里必须设
'app_debug' => false，且确认没有被运行时代码覆盖 - 关掉模板编译缓存（
'template.cache' => false）和日志实时写入（'log.file' => false） - 如果要用日志，改用异步写入（如
think\facade\Log::channel('daily')）或转发到 syslog - 检查
config/log.php中是否误开了'sql_log' => true，这个开关在 debug 关闭后仍可能生效
真正卡住人的往往不是单个函数，而是 debug 状态 + 全字段查询 + 静态缓存 + G() 打点这四层叠加。删掉任意一层，内存峰值可能就从 384MB 掉到 96MB。别急着改 memory_limit，先 grep 一遍项目里所有 G(、static $、select( 和 app_debug 出现的位置。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
