PHP（Laravel）项目CRUD操作替代ID的唯一值选用方案咨询

现有方案可行性评价 #

你提到的新增独立hash字段、使用UUID/CUID作为唯一标识的方案都可落地，其中还有更贴合Laravel生态、维护成本更低的实现方式可选：

• 自定义hash字段方案：优势是和主键逻辑完全解耦，可自由定制生成规则；劣势是需要额外维护字段的唯一约束，新增数据时要提前生成hash并处理碰撞风险，开发维护成本更高，没有特殊定制需求的话不做优先推荐。
• UUID/CUID作为主键方案：Laravel 9及以上版本原生支持UUID、ULID作为主键，仅需要在迁移文件中将主键定义为$table->uuid('id')->primary()或者$table->ulid('id')->primary()，再给模型引入对应的HasUuids/HasUlids trait即可自动生成标识，无需手动维护。CUID、ULID相比传统UUID有序性更好，索引性能损耗更低，更适合URL场景使用。唯一的劣势是相比自增ID有轻微的索引性能下降，单表百万级数据量下几乎感知不到。

更推荐的低成本方案 #

如果不想改动现有表结构，优先选择Hashids方案，无需新增任何数据库字段：
你可以通过Hashids扩展，基于自定义盐值将自增ID转换为非连续的字符串标识暴露给前端，前端传递该标识后后端再解密为原始ID做查询，全程不会暴露自增ID，也完全避免了碰撞风险。
Laravel生态有对应的Hashids扩展可以直接使用，核心实现代码参考：

// 模型中新增访问器，对外暴露hash_id
public function getHashIdAttribute()
{
    return Hashids::encode($this->id);
}

// 路由服务提供者中配置路由模型绑定，自动解析hash_id为模型实例
Route::bind('article', function ($value) {
    $id = Hashids::decode($value)[0] ?? null;
    return Article::findOrFail($id);
});

必须做的安全兜底 #

无论选用哪种外部标识方案，都必须加用户归属校验逻辑，避免标识被暴力猜解后导致的数据泄露。Laravel中可以通过全局查询作用域一键实现，无需每个查询手动加条件：

// 对应模型的booted方法中注册全局作用域
protected static function booted()
{
    static::addGlobalScope('owner', function ($query) {
        $query->where('user_id', auth()->id());
    });
}

选型建议 #

• 存量项目不想改表结构：优先选Hashids方案，零表结构改动，实现成本最低
• 新项目未上线：优先选ULID/CUID作为主键，Laravel原生支持，后续无需额外处理标识转换逻辑
• 有特殊自定义标识规则需求：再考虑手动新增hash字段的方案

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