Firestore中自定义对象与安全规则强制数据库Schema的选型疑问

已实现的自定义对象方案 #

我目前通过自定义对象结合Firestore数据转换器实现类型校验，示例代码如下：

class City {
    constructor ( name, state, country ) {
        this.name = name;
        this.state = state;
        this.country = country;
    }
    toString() {
        return this.name + ', ' + this.state + ', ' + this.country;
    }
}

// Firestore数据转换器
const cityConverter = {
    toFirestore: (city) => {
        return {
            name: city.name,
            state: city.state,
            country: city.country
        };
    },
    fromFirestore: (snapshot, options) => {
        const data = snapshot.data(options);
        return new City(data.name, data.state, data.country);
    }
};

使用方式：

const ref = doc(db, "cities", "LA").withConverter(cityConverter);
await setDoc(ref, new City("Los Angeles", "CA", "USA"));

同时我结合TypeScript给构造函数添加类型约束，提前发现开发者的类型错误：

constructor ( name : string , state : string, country : string )

Firebase安全规则的独特优势 #

虽然自定义对象方案能在开发阶段有效约束类型，但安全规则有几个不可替代的优势：

• 终极防线，覆盖所有写入入口：自定义对象只约束通过应用代码写入的数据，但如果有人绕过前端/后端代码，直接通过Firebase控制台、API或第三方工具写入数据，安全规则能拦截不符合Schema的请求，从数据库层面确保数据一致性。
• 集中式管控：安全规则在Firebase后台配置，无需修改应用代码就能更新Schema校验逻辑，适合团队协作或多端应用场景，避免各端代码同步更新的麻烦。
• 权限与校验结合：安全规则不仅能校验数据类型，还能同时验证写入者的权限（比如是否是合法用户、是否有修改该文档的权限），把数据合法性校验和访问控制整合在一起，减少重复逻辑。

生产环境的选择建议 #

生产环境中，两者结合才是最优方案：

• 自定义对象+TypeScript作为开发阶段的第一道关卡，提前发现代码中的类型错误，提升开发效率。
• 安全规则作为数据库层面的最后防线，确保无论数据从哪个入口写入，都符合预设的Schema和权限要求，避免脏数据进入数据库。

安全规则的核心优势并非“隐蔽”，而是它能覆盖所有写入场景，是保障数据一致性的必要手段，无法被自定义对象方案完全替代。

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