Symfony2电商商品查询模块应围绕“查得准、查得快、查得稳”构建：先规范实体关系映射，再用QueryBuilder封装动态条件与多对多“AND”筛选，最后通过Repository收口、API分层暴露，避免N+1与控制器膨胀。
用 Symfony2 搭建电商商品查询模块，核心不是堆砌 ORM 方法，而是围绕“查得准、查得快、查得稳”三层目标组织代码：先理清商品、分类、属性、库存等实体关系；再用 QueryBuilder 封装动态条件与关联逻辑；最后通过 Repository 收口、API 分层暴露，避免控制器膨胀和 N+1 陷阱。
实体关系设计与基础映射
电商商品通常涉及多对一（分类）、多对多（标签/属性）、一对一（主图）等关系。不要跳过映射定义直接写查询：
- 商品（Product）与分类（Category）用
ManyToOne，确保category_id字段存在且加索引 - 商品与属性（Attribute）需中间表（product_attributes），Doctrine 中声明为
ManyToMany，并启用inversedBy/mappedBy - 价格、库存等高频筛选字段，建议设为
@ORM\Column(type="decimal", precision=10, scale=2)，避免 float 精度问题 - 状态字段（如
status）用字符串枚举（'draft'/'active'/'sold_out'），别用整数码——可读性高、迁移安全
QueryBuilder 动态查询封装（含多条件+多对多“与”筛选）
用户搜索常带“品牌=A 且 颜色=红 且 尺码=L”，这类“AND 多属性”必须用多次 JOIN + 独立别名，不能在一个 attributes 表上叠加多个 WHERE：
- 在
ProductRepository中定义方法findFilteredProducts(array $filters) - 对每个属性条件单独 JOIN：
$qb->join('p.attributes', 'a0')->andWhere('a0.slug = :slug0')，下一个条件用a1和:slug1 - 价格区间、关键词模糊匹配等普通条件，用
if (isset($filters['min_price']))判断后追加andWhere()，参数名保持唯一 - 分页固定加
->setFirstResult($offset)->setMaxResults($limit)，避免前端传非法值
视图辅助复杂统计查询
销量榜、月度热卖、类目聚合等报表类查询，SQL 复杂且执行频次低，适合下沉到数据库视图：
- 在 MySQL 中手动创建视图
sales_summary_by_month，含product_id、month、total_qty、revenue - 新建只读实体
SalesSummaryView，顶部加@ORM\Entity(readOnly=true)，字段全用@ORM\Column显式声明 - 在对应 Repository 中写
findTopByMonth($year, $month)，内部用createQueryBuilder('v')查询视图列，禁止join() - 开发时把视图 SQL 脚本放入
migrations/目录，与业务表变更统一管理
API 层规范与防坑要点
商品查询最终面向前端或 App，接口需兼顾 RESTful 原则与实际可用性：
- URL 设计按资源层级：GET
/api/products（列表）、GET/api/products/{id}（单个）、GET/api/categories/{slug}/products（分类下商品） - 过滤参数走 query string：
?status=active&min_price=99&color=red&size=L，后端统一解析进$filters数组 - 响应中禁用懒加载：显式
leftJoin('p.category', 'c')并addSelect('c.name AS category_name')，不依赖$product->getCategory()->getName() - 序列化时用 Groups 控制字段：商品列表返回
id/name/price/image_url，详情页才加description/specs
