Firestore 不支持直接使用 serverTimestamp() 作为对象字段名，必须改用客户端时间戳或通过两步操作（先存值、再读取、再更新键）实现服务端时间戳的键化存储。
firestore 不支持直接使用 `servertimestamp()` 作为对象字段名，必须改用客户端时间戳或通过两步操作（先存值、再读取、再更新键）实现服务端时间戳的键化存储。
在 Firebase Firestore 中，serverTimestamp() 是一个占位符，仅在文档写入时由服务器解析为真实时间戳，它本身不是实际的 JavaScript Date 对象或字符串，而是一个特殊标记对象。因此，当你执行 obj[ts] = event 时，ts 实际上是 { _methodName: "serverTimestamp" } 这类内部对象，其默认 toString() 结果为 "[object Object]"，导致字段名变成 [object Object] —— 这正是你看到 obj: {\[object object\]: event} 的根本原因。
✅ 正确方案一：使用客户端时间戳（推荐，简单可靠）
若业务允许毫秒级精度且能接受客户端时间（需确保设备时间基本准确），可直接用 Date.now() 或 new Date().toISOString() 生成唯一、可排序的键：
const timestampKey = new Date().toISOString(); // 如 "2024-06-15T08:32:15.789Z"
// 或更紧凑的格式（适合排序）
const compactKey = Date.now().toString(); // "1718440335789"
let obj = {};
obj[timestampKey] = event;
await setDoc(docRef, { events: obj }, { merge: true });
✅ 优势：单次写入、原子性强、性能好；
⚠️ 注意：避免依赖 new Date() 的绝对精度，建议结合 NTP 校准或使用后端时间（见方案二）。
✅ 正确方案二：服务端时间戳 + 两步写入（强一致性保障）
若必须使用 Firestore 服务端时间（如审计、防篡改场景），需分两步操作：
- 第一步：写入一个临时文档字段（如 tempTimestamp），使用 serverTimestamp()；
- 第二步：读取该字段的真实值，再构造新对象并更新 events 字段。
// Step 1: 写入服务端时间戳（作为值）
await setDoc(docRef, {
tempTimestamp: serverTimestamp()
}, { merge: true });
// Step 2: 读取并提取真实时间戳
const doc = await getDoc(docRef);
const realTs = doc.data()?.tempTimestamp; // 此时已是 Date 对象
if (realTs) {
const key = realTs.toISOString(); // 转为标准字符串键
const updatedEvents = { ...doc.data()?.events, [key]: event };
await setDoc(docRef, { events: updatedEvents }, { merge: true });
}
? 进阶优化：将此逻辑封装为 Cloud Function（HTTP 或 callable），由服务端统一处理，避免客户端时间偏差与竞态问题。
⚠️ 关键注意事项
- ❌ 不要尝试 JSON.stringify(serverTimestamp()) 或 ts.toString() —— 均无法获得有效时间字符串；
- ❌ 避免在前端用 Date.now() 拼接多个事件后批量写入，可能因网络延迟导致时间顺序错乱；
- ✅ 推荐对时间戳键做标准化处理（如 toISOString() 或 toUTCString()），确保跨时区可排序；
- ✅ 若需按时间范围查询，强烈建议额外维护一个数组型时间索引字段（如 eventTimes: ["2024-06-15T08:32:15Z", ...]）或使用子集合，因为 Firestore 不支持对动态字段名（如 events."2024-06-15T..."）进行范围查询。
总之，时间戳作为键的本质需求，往往暗示着数据建模可优化。若事件频繁增删或需按时间查询，更健壮的设计是将每个事件存为独立子文档（/events/{eventId}），并用 createdAt 字段 + 复合索引支撑高效查询 —— 这才是 Firestore 的推荐范式。
