属性模式建模多语言商品名称更可靠可扩展，避免硬编码字段导致的Schema频繁变更、索引爆炸和查询性能下降；应使用name数组+lang/value结构并建立复合多键索引。
直接用属性模式（Attribute Pattern）建模多语言商品名称，比硬编码字段（如 name_en、name_zh）更可靠、可扩展，也避免生产环境频繁改 Schema 和索引爆炸。
为什么不能用 name_en / name_zh 这类字段？
看似省事，但实际会卡住后续迭代：
- 新增小语种（比如
name_pt-BR）必须alter集合、加字段、重建索引——线上不敢动 - 查“中文名是‘手机’的所有商品”得写
{ $or: [ { "name_zh": "手机" }, { "name_ja": "手机" } ] }，无法走单一索引，性能掉得快 - 90% 商品只填了英文，其余字段全为
null，BSON 存储膨胀、压缩率低、扫描慢
属性模式怎么组织商品名称？
把语言标识作为数组元素的 lang 字段，值统一放 value，结构扁平、可索引：
{ "_id": "prod-123",
"sku": "A1001",
"name": [
{ "lang": "en", "value": "Wireless Earbuds" },
{ "lang": "zh-CN", "value": "无线蓝牙耳机" },
{ "lang": "ja", "value": "ワイヤレスイヤホン" }
]
}
关键点：
- 必须在
name.lang和name.value上建复合多键索引：db.products.createIndex({ "name.lang": 1, "name.value": 1 }) - 查中文名就用：
db.products.find({ "name.lang": "zh-CN", "name.value": "无线蓝牙耳机" })，能命中索引 - 不要用
$elemMatch做等值查询——它不走多键索引；也不要写"name.0.value"这种下标依赖，改用arrayFilters
查询和更新时最容易踩的坑
属性模式不是“扔进去就能用”，几个实操细节决定成败：
- 更新单个语言值必须用
$set+arrayFilters，例如：db.products.updateOne({ _id: "prod-123" }, { $set: { "name.$[elem].value": "新版无线蓝牙耳机" } }, { arrayFilters: [ { "elem.lang": "zh-CN" } ] }) - 聚合时若需取某语言最新翻译，
$unwind后可能重复文档，记得加$group或用$first控制 - 如果 80% 商品只有英文，其余语言极少，可混合建模：高频语言（如 en）单独字段
name_en，低频语言走name_i18n数组，省空间也省索引开销
真正麻烦的不是建模本身，而是索引策略和更新逻辑——一旦写错 arrayFilters 条件或漏建复合索引，查询就退化成全表扫描，而问题往往在线上压测时才暴露。
