应使用嵌套文档数组存储动态属性，而非固定字段：因属性变化频繁易致schema失控、字段稀疏浪费存储、逼近16MB BSON上限；统一用attributes数组，每个元素含name、value（存原生类型）、type；高频查询需建复合索引如{"attributes.name":1,"attributes.value":1}，避免单独索引value；属性量不大时无需拆表，保持原子更新。
直接结论：别用固定字段存动态属性，用嵌套文档数组 + 索引优化，配合 attribute_name 和 attribute_value 两个标准键。
为什么不能把每个属性当字段（如 color、size、material）硬编码进文档？
商品属性变化频繁时，硬编码字段会快速导致 schema 失控：新增类目要改应用代码、加字段、甚至触发全量迁移；不同品类属性重叠率低（比如“CPU主频”只在手机/电脑出现，“是否有机认证”只在食品类存在），字段稀疏严重，浪费存储且影响查询性能；MongoDB 的 BSON 文档有 16MB 上限，字段爆炸式增长容易逼近上限。
实操建议：
- 放弃
{ name: "iPhone 15", color: "Black", size: "6.1in", ... }这类结构 - 统一用
attributes数组，每个元素是{ name: "color", value: "Black", type: "string" }形式 -
type字段保留可选，用于后续类型校验或前端渲染判断（如"boolean"渲染开关，"number"支持范围筛选）
如何高效查“所有有机认证的食品”或“内存 ≥ 16GB 的笔记本”？
数组字段天然支持 $elemMatch，但仅靠它不够——没有索引时，全表扫描 attributes 数组极慢。必须建复合索引，且顺序关键。
实操建议：
- 对高频查询组合建索引，例如：
db.products.createIndex({ "attributes.name": 1, "attributes.value": 1 }) - 如果常按类目+属性联合过滤（如
category: "laptop"+attributes.name = "ram"），索引应为{ category: 1, "attributes.name": 1, "attributes.value": 1 } - 避免在
attributes.value上单独建索引——值类型混杂（字符串/数字/布尔），MongoDB 无法有效排序，索引选择性差
属性值是数字或布尔时，value 字段该存字符串还是原生类型？
存原生类型（16、true）更合理。MongoDB 查询和索引对原生类型支持完整，而字符串化后会导致数值比较失效（如 "16" > "8" 成立，但 "16" > "128" 也成立）、无法用 $gt/$lt 直接操作。
实操建议：
- 服务端写入前做类型推断或显式转换：识别出
"16"→16，"true"→true，"2023-01-01"→ISODate("2023-01-01") - 前端传参时带
value_type字段辅助解析，如{ name: "ram", value: "16", value_type: "number" } - 不强求所有
value同类型，MongoDB 允许数组内元素异构，只要查询逻辑适配即可
要不要拆成单独的 product_attributes 集合？
除非单个商品属性超 500 条或属性本身需独立增删审计（如“用户提交的规格纠错”），否则不要拆。跨集合 join 在 MongoDB 中代价高（$lookup 性能敏感），应用层聚合复杂，且失去原子性更新能力（改商品名和改属性需两步事务）。
实操建议：
- 保持
attributes在主文档内，利用 MongoDB 的文档局部更新（$set: {"attributes.$[elem].value": "Red"}）精准修改 - 若属性量极大（如工业设备含上千传感器参数），再考虑分离，并用
product_id做双向引用 + TTL 索引控制历史版本 - 注意：分片集合下，
attributes数组不能作为分片键路径的一部分，分片键得选稳定字段如_id或category
最易被忽略的是索引字段路径里的点号写法："attributes.name" 必须带引号，否则 shell 会报错；还有就是批量更新时用 arrayFilters 的匹配条件必须严格对应 name 值，大小写和空格都影响结果——这些细节不踩一遍很难记住。
