我能够通过重组数据模式来解决此问题，将用户ID放在路径中，而不是对象中，例如/users/< -uid->/notes/，并使用以下规则...

I was able to solve this by restructuring my data schema, putting the user id in the path, not in the object, e.g., /users/<-uid->/notes/, and using the following rules...

{
  "rules": {
    "users": {
      "$userId": {
            ".read": "$userId === auth.uid",
            ".write": "$userId === auth.uid"   
      }
    }
  }
}

根据有关规则不是过滤器"的评论，我现在明白了.让我感到困扰的是，Firebase数据库规则文档所指的是具有键值对的子级"，例如，...

As per the comments regarding "rules are not filters", I get that now. The thing that was tripping me up was where the Firebase database rules doc was referring to "children" with key-value pairs, e.g.,...

此示例仅在isReadable子级设置为的情况下才允许读取 在读取的位置为真.

This example only allows reading if the isReadable child is set to true at the location being read.

".read": "data.child('isReadable').val() == true"

对我来说，这意味着JSON数据结构就是这样...

To me that implied that the JSON data structure is something like this...

{ ..., isReadable: true, ...}

但是我想这是指位置路径，例如/users/fred/isReadble或类似的东西.不太确定.好像很奇怪但是无论如何，我都能正常工作.

But I guess that is referring to location paths, e.g., /users/fred/isReadble or something like that. Not quite sure. It seems odd. But regardless, I got it working.