MongoDB事务中不能创建临时集合，包括以temp前缀、system.或$开头的集合；所有集合必须预先显式创建且命名合规，事务仅支持对已存在常规集合执行CRUD操作。
事务里不能创建临时集合
MongoDB 不允许在事务中创建 temp 前缀的集合，也不支持任何带 system. 或 $ 开头的内部集合。事务只允许操作显式创建的、常规命名的集合（如 orders、users）。所谓“临时集合”如果指应用层模拟的短生命周期集合（比如按小时建的 logs_20260708_06），只要它不是系统保留名、且已预先存在，就能在事务中读写——但创建动作本身必须在事务外完成。
事务内对临时集合的读写会触发 snapshot 读关注限制
如果你把某个集合当成“临时”用（比如高频写入后定期 drop），又在事务里用 readConcern: "snapshot" 读它，要注意：MongoDB 5.0+ 要求该集合不能是 capped（固定大小）集合。而很多临时日志类集合恰恰是 capped 的。一旦违反，事务启动直接报错：read concern 'snapshot' is not supported for capped collections。这不是临时性导致的，而是 capped 属性与 snapshot 不兼容。
事务未提交时，临时集合上的写操作无法被其他事务/会话立即看到
这是 MVCC 的正常行为，但容易被误判为“写丢了”。比如你在事务 A 中向 tmp_events 插入文档，同时事务 B 尝试读取该集合（无论是否加 readConcern），都看不到 A 的变更——除非 B 显式指定 readConcern: "majority" 且 A 已提交。更关键的是：如果事务 A 长时间未提交，这些未提交的写会持续占用 WiredTiger page 空间，加剧碎片，而 compact 又不能在事务活跃时运行，形成卡点。
临时集合被 drop 后再重建，事务里引用它会失败
事务执行期间，如果另一个会话执行了 db.tmp_cache.drop()，而你的事务里正要往 tmp_cache 写数据，会立刻报错：NamespaceNotFound。MongoDB 不会在事务开始时做集合存在性快照，而是每次操作前实时校验。所以“临时集合”生命周期若由外部调度控制（比如定时清理脚本），必须确保和事务窗口无重叠——建议用独立命名（含时间戳）+ TTL 索引替代手动 drop。
