firestore 不支持对单个文档内的数组字段直接分页，因为读取文档时会加载全部内容；真正的分页应作用于集合查询，且单文档大小上限为 1 mib，无法存储“百万级”数据。
在 Firestore 中，文档是原子读写单元——无论你只想要其中某个字段或数组的一部分，调用 .get() 时 SDK 都会下载整个文档（包括所有嵌套字段和数组元素）到内存。这意味着：
- ✅ 你可以用 Python 对 document.to_dict()['posts'] 进行内存内切片（如 posts[0:20]），实现逻辑分页；
- ❌ 但这不是真正的服务端分页，无法节省带宽或降低延迟，也无法规避单文档大小限制。
# 示例：内存内模拟分页（不推荐用于大数据量）
doc = collection.document(str(document_id)).get()
if doc.exists:
data = doc.to_dict()
posts = data.get("posts", [])
page_size = 10
start_idx = 0 # 可替换为动态 offset
current_page = posts[start_idx : start_idx + page_size]⚠️ 关键限制必须牢记：
- Firestore 单文档最大容量为 1 MiB（约 100 万字节），实际可存储的数组长度远低于“数千甚至百万”——例如，若每条 post 平均 1 KB，则最多存约 1000 条；
- 超出限额将导致写入失败（ResourceExhausted 错误），且无法通过客户端 SDK 规避。
✅ 正确的架构设计建议：
- 将“用户帖子”建模为独立子集合（如 users/{uid}/posts），而非文档内数组；
- 使用 Firestore 原生分页能力（start_after() / limit()）查询子集合，真正实现服务端分页、按需加载、权限精细控制：
# 推荐：基于子集合的服务端分页
posts_ref = db.collection("users").document(user_id).collection("posts")
query = posts_ref.order_by("created_at", direction=firestore.Query.DESCENDING).limit(10)
first_page = query.get()
# 获取最后一条用于下一页
last_doc = list(first_page)[-1] if first_page else None
if last_doc:
next_query = posts_ref.order_by("created_at", direction=firestore.Query.DESCENDING)\
.start_after(last_doc).limit(10)? 总结：不要把高基数关系型数据（如用户海量帖子）塞进单文档数组。利用 Firestore 的集合/子集合模型，配合 limit() 和游标分页，才能获得可扩展、低延迟、符合配额约束的生产级实现。
