Firebase Storage安全规则：match语句是否匹配文件名任意位置的字符串？

先贴出你提供的规则代码：

service firebase.storage {
  match b/{bucket}/o {
    // Matches any filename containing string '/images/'.
    match /images/{imageId} {
      allow read, write: if false;
    }

    // Matches all filenames containing string `/images/`
    match /images/{imageId=**} {
      allow read, write: if true;
    }
  }
}

直接给结论：你提到的/foo/bar/images/profilePicture.png这类路径不会被上面的第二条规则匹配到，官方说明里的“任意位置包含/images/”描述有误导性，或者对应的是另一种规则写法。

下面拆解规则的实际匹配范围：

• 第一条match /images/{imageId}：用的是单层通配符，只匹配/images/后面跟单个层级的文件，比如/images/photo.png，连/images/avatars/photo.png都匹配不到，更别说路径中间才出现/images/的情况。
• 第二条match /images/{imageId=**}：用了递归通配符**，能匹配所有以/images/开头的任意深度路径，比如/images/subdir/avatar.png、/images/a/b/c/file.jpg这类，但依然只认路径开头是/images/的对象，路径中间出现/images/的文件根本触发不了这条规则。

如果真要匹配**任意位置包含/images/**的文件，规则得这么写：

service firebase.storage {
  match b/{bucket}/o {
    match {prefix=**}/images/{suffix=**} {
      allow read, write: if true;
    }
  }
}

这里{prefix=**}会匹配/images/之前的任意路径（包括空路径），{suffix=**}匹配之后的任意路径，这样才能覆盖所有路径里带/images/的对象。

回到你给的规则，之所以官方说“任意位置”可能是表述错误，实际第二条规则只作用于以/images/开头的对象。而规则重叠后最终允许操作的原因是：只要有一条规则允许，操作就会被允许——比如/images/photo.png同时匹配两条规则，第一条禁止但第二条允许，所以最终能读写。

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