先说说结论：在报表场景中，不能依赖单一的“通用文档结构”来应对所有需求，必须根据具体报表的查询频次、字段组合方式、更新节奏进行分层设计——高频固定报表采用预聚合嵌入，动态维度报表使用多态模型配合稀疏索引，原始明细数据则单独存储。

预聚合字段该不该放进主文档？

当然应该放入，但仅限于那些真正高频查询、低频更新、且计算成本较高的聚合结果。举例来说，电商后台“用户昨日订单数+总金额”这类固定口径指标，直接存储在 users 集合的 report_summary 字段里，使用 $inc 原子更新即可满足需求。

• 避免将所有报表字段都堆砌到主文档中——像“最近7天退货率”“跨品类复购率”这类计算逻辑复杂、更新间隔较长的指标，应独立存放在 user_reports 集合中，采用 user_id + report_type + date_range 作为复合主键
• 不要在预聚合字段中存储原始明细数据（例如订单ID列表），16MB的文档大小限制很快会触发文档迁移；如需查询明细，应通过 $lookup 或应用层关联实现
• 务必确保时区一致性：所有预聚合时间字段统一使用UTC存储，由应用层负责时区转换，否则跨时区报表数据会出现偏差

如何支持用户自定义维度筛选？

采用多态文档结合稀疏索引的方案，而非设计一个通用的 custom_fields 数组。MongoDB允许同一集合内文档结构不同，这正是其独特优势所在。

• 例如销售报表需要按“地区/渠道/促销类型”组合筛选，就让每个文档携带对应字段：{"region":"华东","channel":"小程序"} 或 {"region":"华北","promotion_code":"SUMMER2026"}，缺失的字段不写入，不填充 null
• 为高频查询的组合条件建立稀疏索引：db.sales.createIndex({region: 1, channel: 1}, {sparse: true})，避免为大量缺失字段建立无效的索引项
• 禁止使用 custom_attributes: [{key:"xxx",value:"yyy"}] 这种键值对数组结构——此类查询无法利用索引，聚合操作中的 $unwind 步骤会严重拖慢性能

原始明细数据怎么存才不影响报表性能？

应当单独建立集合，按时间分桶存储，避免与业务主文档混杂。报表的核心需求是统计结果，而非实时查询百万级明细数据。

• 例如用户行为日志，按小时建立集合：events_20260706_14、events_20260706_15，并使用TTL索引自动过期（{expireAfterSeconds: 2592000}）
• 明细文档的字段尽量精简：只保留 user_id、event_type、timestamp、payload（必要的上下文JSON），移除所有冗余描述字段
• 报表聚合应使用 aggregate() 管道，避免用 find() 拉取全量数据——尤其不要在大集合的聚合中直接使用 $lookup 关联，应优先采用 $facet 或分步预计算

还有一个常被忽略的要点：每次报表需求变更，文档结构都可能随之调整。所谓的“灵活性”，并非依赖一个schema支撑所有可能性，而是依靠快速迭代能力——借助MongoDB的无模式特性，在 report_configs 集合中存储每张报表的字段映射规则，再由应用层动态生成聚合管道，这才是真正可落地的灵活性方案。