使用日期作为Firestore文档ID是否为合理的开发实践？

结论：优先选择「使用ISO 8601格式日期字符串作为文档ID」的方案，完全适配你的核心需求，综合表现远优于第二种方案。

方案一的核心优势 #

• 查询效率最高
  所有数据库的主键ID查询都是性能最高的查询路径，不需要为日期字段额外建立索引，也不需要扫描其他文档，单次查询就能直接拿到结果。如果用第二种方案，你需要额外为日期字段建立唯一索引，即使有索引，查询性能也低于主键ID查询，还需要额外处理唯一约束冲突的问题。
• 核心逻辑实现更简洁
  你的核心需求「检查指定日期文档是否存在，存在则拉取、不存在则新建」可以直接用数据库的upsert（存在更新/返回，不存在插入）能力实现，仅需要一次交互就能完成全流程，不需要先查询符合日期的文档ID，再执行后续操作，代码复杂度更低，也天然避免了并发场景下同一天插入重复文档的问题。
• ID自带语义，降低维护成本
  ISO 8601格式的日期ID天然具备排序能力，你只需要扫描文档ID列表就能直接看到哪些日期有对应日记，不需要逐一读取文档内容的日期字段，排查问题、批量导出数据时效率更高。如果需要按日期范围批量拉取文档，直接按ID范围查询即可，不需要额外写日期字段的过滤条件。

注意事项 #

使用该方案时需要统一日期格式化规则与时区标准：

1. 固定使用YYYY-MM-DD格式的ISO 8601字符串作为ID，不要混用其他格式
2. 统一日期的时区标准，要么全部转换为UTC日期生成ID，要么固定用用户本地时区生成ID，避免同一用户同一天因为时区偏移生成两个不同的文档ID。

方案二的适用场景 #

只有当你后续需求变更为「单日支持创建多篇日记」，且有大量非日期维度的查询需求时，才需要考虑使用随机ID+日期字段的方案，你的现有需求完全不需要使用该方案。

内容的提问来源于stack exchange，提问作者Dalon