firestore 文档内数组字段无法直接分页，因单文档读取必加载全部内容；应改用子集合存储并结合查询分页，同时严格遵守 1mib 文档大小限制。
在 Firestore 中，文档（Document）是原子读写单元——无论你只访问其中某个字段或数组元素，调用 .get() 时 SDK 都会完整下载整个文档到内存。这意味着：
✅ document.to_dict() 或 document.get('posts') 并不会“按需加载”，而是基于已拉取的完整快照做本地提取；
❌ 你无法对文档内的 posts 数组实现服务端分页（如跳过前 20 条、取下 10 条），因为 Firestore 不支持对单文档字段进行分页查询。
⚠️ 根本限制：文档大小上限为 1 MiB
Firestore 明确规定单文档最大尺寸为 1,048,576 字节。若 posts 是包含数千条记录的数组（尤其含文本、时间戳、嵌套对象），极易触达该上限。所谓“百万级数据存于单文档”在技术上不可行，也违背 NoSQL 最佳实践。
✅ 正确方案：用子集合（Subcollection）替代数组字段
将每个用户的帖子从 users/{uid}/posts: [] 迁移为独立子集合 users/{uid}/posts/{post_id}：
from google.cloud import firestore
db = firestore.Client()
user_ref = db.collection("users").document("alice")
# ✅ 写入：每条帖子作为独立文档
post_ref = user_ref.collection("posts").document()
post_ref.set({
"title": "My First Post",
"content": "...",
"created_at": firestore.SERVER_TIMESTAMP,
"order_index": 1000 # 可用于排序
})
# ✅ 分页读取（服务端分页，真正高效）
def get_user_posts_paginated(user_id: str, last_snapshot=None, limit=10):
posts_ref = db.collection("users").document(user_id).collection("posts")
query = posts_ref.order_by("created_at", direction=firestore.Query.DESCENDING).limit(limit)
if last_snapshot:
query = query.start_after(last_snapshot)
docs = query.stream()
results = [doc.to_dict() for doc in docs]
# 返回结果 + 下一页游标（最后一条文档快照）
return results, list(docs)[-1] if results else None
# 使用示例
posts, cursor = get_user_posts_paginated("alice")
next_posts, next_cursor = get_user_posts_paginated("alice", cursor)? 关键优势
- 服务端分页：仅传输指定数量的文档，内存与网络开销可控；
- 可扩展性：子集合支持索引、复合查询、安全规则精细化控制；
- 一致性：每条帖子可独立更新/删除，避免数组操作引发的并发冲突；
- 可观测性：可通过 Firebase 控制台直观查看和调试。
? 注意事项
- 避免在客户端拼接大量数组后手动切片（如 posts[20:30]）——这仍需先加载全部数据，丧失分页意义；
- 若必须保留数组结构（极少数场景），可结合 array-contains 等查询，但不解决分页问题；
- 迁移历史数据时，使用批量写入（WriteBatch）提升效率；
- 在安全规则中显式授权子集合访问：
match /users/{userId}/posts/{postId} { allow read: if request.auth != null && request.auth.uid == userId; }
综上，请放弃“对文档内数组分页”的思路——这不是 Firestore 的设计范式。拥抱子集合 + 查询分页，才是处理海量用户生成内容（UGC）的可靠路径。
