应优先使用 withCount() 和 withSum()，仅在需跨模型条件过滤、复杂聚合或性能优化时才手写 JOIN；注意关联名拼写、外键类型一致、软删除处理、stringify_fetches 关闭、DECIMAL 字段类型及 GROUP BY 正确性。
直接用 withCount() 和 withSum()，别手写 JOIN + field + group —— 除非你明确需要控制 SQL 或做跨模型条件过滤。
withCount() 统计关联记录数，但返回 0 或报错？
常见错误是调用了 withCount('orders')，结果所有 orders_count 都是 0，甚至抛出 SQLSTATE[42000]: Syntax error or access violation。
- 检查关联方法名是否拼错：模型里定义的是
orders()，withCount()就必须传'orders'，大小写和复数都敏感 - 确认外键字段存在且类型一致：比如
Order模型中user_id是INT，而User主键是BIGINT，MySQL 会静默转成 0 匹配，导致统计为空 - 软删除没处理：如果
Order启用了软删除（delete_time字段），withCount()默认不自动过滤已删除记录，得加闭包：withCount(['orders' => function ($q) { $q->whereNull('delete_time'); }]) - 一对多关联下，
withCount()生成的子查询是(SELECT COUNT(*) FROM orders WHERE user_id = users.id)，不会受主查询where影响；但如果你在withCount()之后又链式调了where()，部分版本会把条件错加到子查询里，建议条件全部前置
withSum() 计算金额总和，结果为 NULL 或字符串？
withSum('orders', 'amount') 返回的 orders_sum 是字符串 "123.45"，后续做 + 运算就变成字符串拼接；或者整行都是 NULL，不是数据为空，而是字段本身允许 NULL 且没值。
- 数据库连接配置里必须关掉
ATTR_STRINGIFY_FETCHES：在database.php中确保'stringify_fetches' => false，否则 MySQL 返回的数字会被 PDO 强转成字符串 -
amount字段类型要是DECIMAL(10,2)，不是VARCHAR或TEXT；MySQL 8.0+ 开启STRICT_TRANS_TABLES时，对非数值字段SUM()会直接报错，不是返回 0 - 要让空关联也返回 0 而不是
NULL，不能靠 PHP 判断，得让数据库返回：withSum(['orders' => function ($q) { $q->field('COALESCE(SUM(amount), 0) AS amount_sum'); }], 'amount')—— 注意这里其实绕开了框架的withSum自动构造，改用field手动写表达式 - 如果统计字段可能为
NULL（比如未付款订单amount为NULL），SUM()会跳过它；要强制当 0 算，得在数据库层用IFNULL(amount, 0)，但withSum()不支持函数表达式，只能换withField()或原生查询
多表 JOIN + SUM 时 group 失效或重复计数？
用 Db::table()->join()->field('SUM(...)')->group() 写法，发现总数比手动查高几倍，或者 group 像没起作用。
立即学习“PHP免费学习笔记（深入）”；
- LEFT JOIN 一对多时，主表一行会因附表多行被“撑开”：比如 1 个用户有 3 个订单，JOIN 后变 3 行，
SUM()就算了 3 次——必须加GROUP BY，且分组字段必须是主表唯一标识，如users.id - 别漏写
alias()：join('orders o', 'u.id = o.user_id')里o是别名，后面field()和group()都得用o.xxx，否则字段找不到 - 多个聚合字段（
COUNT+SUM）混用时，不能同时选普通字段（如u.name）而不GROUP BY u.name，MySQL 直接报ERROR 1140，ThinkPHP 不拦截，得自己盯 SQL - 索引没建好时，
GROUP BY会变全表扫描：给orders.user_id加索引，比优化 PHP 代码管用十倍
什么时候该放弃 withCount/withSum，改用手写 JOIN？
不是所有场景都适合封装方法。以下情况建议退回到 Db::table() + join()：
- 要统计的字段不在关联模型主表，而在中间表或三级关联表（比如用户 → 订单 → 订单商品 → 商品分类）
- 需要对关联数据做复杂条件聚合，例如 “统计近 30 天已发货订单的实付金额总和”，这个时间条件没法塞进
withSum()的闭包里不影响主查询逻辑 - 主模型用了
scope或动态where，而关联统计需要不同条件，withCount()闭包无法复用主查询的 where 链 - 性能敏感且数据量大：
withCount()是 N+1 查询（主查 + 每行一个子查），而 JOIN 是单次查询；但注意，JOIN 在大数据量下也可能因笛卡尔积拖慢，得看执行计划
最易被忽略的一点：withSum() 和 withCount() 返回的统计字段名是硬编码规则（关联方法名 + _sum / _count），一旦模型里改了关联方法名，所有模板和 API 输出都要跟着改——不如在控制器里显式赋值，更可控。
