Firestore安全规则仅允许按文档ID过滤list操作的相关问题

1. 当前实现是否为正确方案 #

不是，你的当前实现依赖了Firestore规则引擎未定义的行为，完全不符合官方规范。控制台告警的逻辑是正确的：在match路径中捕获的question_id通配符，在list规则的评估上下文中本身永远不会为null，这个判断在规范层面应该永远返回true，等于直接放开了所有list权限。

2. 现有实现还能正常使用多久 #

随时可能失效。当前你在模拟器中看到的符合预期的效果属于未定义行为，Firebase团队已经通过告警提示了该表达式的问题，后续版本修复规则评估逻辑的一致性问题后，该规则会直接永久返回true，你的全量查询拦截逻辑会完全失效。更需要注意的是，当前生产环境的规则大概率已经不符合你的预期，已经存在全量数据泄露的风险。

3. 正确的编写方式 #

直接通过request.query判断查询是否携带了文档ID的过滤条件即可，官方推荐写法如下：

match /questions/{questionId} {
  // 允许按文档ID的等于、in查询执行list操作
  allow list: if request.query.where.keys().hasAny(["__name__"]) 
    && (request.query.where["__name__"].op in ["==", "in"]);
  // 可按需补充单文档get权限的判断逻辑
  allow get: if true;
}

如果需要更严格的权限控制，比如仅允许用户查询指定范围内的ID，还可以结合业务逻辑做二次校验，示例如下：

allow list: if request.query.where.keys().hasAny(["__name__"]) 
    && (request.query.where["__name__"].op in ["==", "in"])
    // 示例：仅允许查询用户自定义声明中携带的允许访问的ID
    && request.query.where["__name__"].value in request.auth.token.allowedQuestionIds;

4. 是否属于模拟器和生产的行为差异 #

是的，这是已知的Firestore规则模拟器与生产环境的行为不一致问题。目前模拟器对路径通配符的非空判断做了不符合规范的特殊处理，才会出现你测试时拦截了全量查询的效果，生产环境下该规则实际会放行所有list请求，与告警描述完全一致。

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