get_category_products() 是获取栏目关联商品最直接的方法，它通过 JOIN 中间表过滤上架且未删除商品，需注意字段名、排序、多级继承、缓存及分页总数一致性。
用 get_category_products() 获取栏目关联商品最直接
商城系统里“栏目关联商品”本质是多对多关系，通常存在中间表（如 category_product）。PHP 中不推荐手写原始 SQL 拼接查询，优先封装成可复用函数。假设你用的是自研轻量框架或原生 PDO，get_category_products($cat_id, $limit = 12) 是最常用入口——它内部会 JOIN 分类表、商品表和中间表，过滤状态为上架（status = 1）、未删除（is_deleted = 0）的商品。
常见错误是只查 products 表而忽略中间表，导致返回空数组；或者没加 ORDER BY sort_order ASC, id DESC，商品顺序随机。
- 务必检查中间表字段名是否为
category_id和product_id（有些项目叫cat_id/pid，需同步调整 SQL） - 如果栏目支持多级（如父栏目自动继承子栏目商品），函数里得递归查出所有子
id后再 IN 查询，别只查当前一级 - 缓存建议用
cache_key = 'category_products_' . $cat_id . '_' . $limit，避免高频重复查库
ThinkPHP 6 中用 with() + 关联定义更安全
TP6 的模型关联能自动处理中间表逻辑，前提是正确配置了 belongsToMany。比如在 CategoryModel 里定义：
public function products()
{
return $this->belongsToMany(ProductModel::class, 'category_product', 'category_id', 'product_id');
}调用时直接写 $category->with('products')->find($id)，框架自动生成三表 JOIN。但要注意几个坑：
立即学习“PHP免费学习笔记（深入）”；
- 中间表名必须全小写且与数据库一致，TP6 默认不识别下划线+驼峰混合命名（如
CategoryProduct模型对应表名不是category_product就会失效） -
with()默认查全部字段，商品列表页只需id、name、price、cover，应追加->field('id,name,price,cover')减少传输量 - 如果商品表有软删除（
delete_time字段），需在ProductModel中设置useSoftDelete('delete_time', 0)，否则关联结果里会出现已删商品
MySQL 直查时 IN 子查询比 JOIN 更快？看数据量
当栏目下商品超 5000 条，或并发请求多时，JOIN 可能触发临时表和 filesort。此时改用两步查更稳：
SELECT product_id FROM category_product WHERE category_id = ? AND status = 1; -- 得到 IDs 数组后 SELECT * FROM products WHERE id IN (1,2,3,...) AND status = 1 ORDER BY sort_order;
这个方案绕过 JOIN 性能瓶颈，但要注意：
-
IN列表长度别超 MySQL 的max_allowed_packet（默认 4MB），单次最多传约 10 万 ID；超量得拆成多次查询 - 必须确保两次查询在同一个事务里读一致性（尤其商品状态可能被后台修改），否则第二步可能查到已被下架的商品
- PHP 中用
array_column($rows, 'product_id')提取 ID 数组，别手动 implode —— 防 SQL 注入要提前 intval 过滤每个 ID
前端分页时 count() 容易漏掉关联条件
列表页分页需要总数，但很多人只写 SELECT COUNT(*) FROM products，忘了加栏目关联约束，导致总页数对不上。正确做法是：
- 用和商品列表完全相同的 WHERE 条件再套一层
COUNT，例如：SELECT COUNT(*) FROM products p INNER JOIN category_product cp ON p.id = cp.product_id WHERE cp.category_id = ? AND p.status = 1 - TP6 中别用
$model->withCount('products')，那是统计“该栏目有多少商品”，不是“该栏目下可展示的商品数”——它不会自动带商品表的状态判断 - 如果用了 Redis 缓存总数，更新商品上下架时，必须同时
DEL对应的category_products_count_{$cat_id}键，否则分页错乱
实际业务中，栏目商品常涉及规格、库存、会员价等动态字段，单纯查主表远远不够。这些扩展字段往往存在单独的宽表或 JSON 字段里，需要额外 LEFT JOIN 或反序列化处理——那部分逻辑得放在商品组装阶段，而不是关联查询里硬塞。
