文档链接分享实现：分享ID选型及最佳实践咨询

问题 #

我最初打算直接用文档ID生成可分享链接，格式为website.com/shared/:id，对应的代码实现如下：

class Item: Object, ObjectKeyIdentifiable {
    @Persisted(primaryKey: true) var _id: ObjectId
    @Persisted var userId: String
    @Persisted var name: String
}

但发现如果恶意用户获取到文档ID，我就无法生成新的分享链接了。因此我考虑设置单独的分享ID，格式改为website.com/shared/:shareId，代码调整如下：

class Item: Object, ObjectKeyIdentifiable {
    @Persisted(primaryKey: true) var _id: ObjectId
    @Persisted var userId: String
    @Persisted var name: String
    
    @Persisted var shareId: ObjectId // or UUID or string
}

想请教两个问题：

1. 直接使用ObjectId或UUID作为分享ID是否可行？
2. 文档分享的最佳实践有哪些？另外我观察到谷歌文档的分享链接仅在编辑链接后添加了?usp=sharing参数，并未使用单独的ID，这是为什么？

解答 #

一、用ObjectId/UUID作为分享ID是否可行？ #

完全可行，理由如下：

• 唯一性保障：ObjectId和UUID都具备极高的唯一性，几乎不会出现重复，能确保每个分享链接对应唯一文档。
• 不可预测性：两者生成逻辑无规律（ObjectId虽包含时间戳但整体仍难猜测，UUID则是完全随机），恶意用户很难通过枚举或猜测获取有效分享ID。
• 实现成本低：无需额外复杂生成逻辑，直接利用现有工具生成即可，存储和查询也都很便捷。

需要注意：如果使用ObjectId，部分场景下可能会暴露文档的创建时间（因为ObjectId包含时间戳信息），若业务有隐私顾虑，优先选择UUID或自定义随机字符串。

二、文档分享的最佳实践 #

结合实际业务场景，推荐以下几点：

1. 使用独立的分享标识
   像你设计的那样，将文档主键ID与分享ID分开，优势在于：

   • 可随时失效或重置分享ID，且不影响文档本身的主键（比如用户怀疑分享链接泄露时，直接生成新的shareId替换旧的即可）；
   • 避免主键ID泄露带来的其他风险（比如主键ID可能被用于删除、修改文档等其他业务操作）。

2. 添加权限验证层
   不要仅依赖分享ID做唯一验证，用户访问分享链接时，还需做：

   • 检查该分享ID对应的文档是否开启了分享权限；
   • 限制访问范围（比如公开分享还是仅指定用户可访问）；
   • 记录访问日志，方便异常排查。

3. 支持精细化的分享权限控制
   比如区分「查看权限」和「编辑权限」，甚至可以设置有效期、访问密码，满足不同场景的分享需求。

4. 支持分享链接的失效与重置
   提供用户手动重置分享ID的功能，当用户怀疑链接泄露时，可一键生成新的分享链接，旧链接直接失效。

三、关于谷歌文档的分享机制 #

谷歌文档没有使用单独的分享ID，是因为它的权限体系与文档本身绑定，而非依赖链接中的ID区分：

• 链接中的长串ID就是文档的唯一标识，?usp=sharing参数仅用于标记该链接为分享入口，引导页面展示分享相关的权限设置；
• 真正的权限控制在后端：用户通过该链接访问时，谷歌会验证当前用户是否拥有该文档的访问权限，而非仅通过链接ID判断；
• 谷歌的文档ID本身已具备极高的不可猜测性，再加上完善的权限体系，即使ID被泄露，无权限的用户也无法访问，因此无需额外的分享ID。

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