权限复制需显式授予角色并确保依赖顺序：先创建角色，再授予权限，最后将角色赋予用户；模板应仅含授权与角色定义语句，使用占位符代替硬编码用户名，避开密码字段和系统角色，并校验语法与依赖。
复制权限时直接用 GRANT ... TO 会丢角色继承关系
postgresql 和 mysql 的权限复制不是“一键克隆”，grant select on table1 to old_user 这类语句只授予权限，不复制角色成员身份（如 old_user 是 readers 角色成员）。新用户即使拿到相同对象权限，也拿不到角色带来的动态权限叠加和未来新增权限。
- 必须显式执行
GRANT role_name TO new_user才能继承角色权限 - PostgreSQL 中还要注意
INHERIT属性：若原用户是CREATE ROLE old_user INHERIT，新用户也得带INHERIT才能自动获得所属角色权限 - MySQL 8.0+ 的角色复制需用
SELECT * FROM mysql.role_edges WHERE TO_HOST = 'old_user'查依赖，再逐条GRANT
用 pg_dumpall --roles 或 mysqldump -u root mysql --tables user db 不适合权限模板化
这类导出包含密码哈希、全局配置、系统账号，混在模板里极易误操作。真正可复用的权限模板应只含「授权语句」和「角色定义语句」，不含登录凭据或运行时状态。
- PostgreSQL 推荐从
pg_roles+pg_auth_members+pg_catalog.pg_*_grants视图拼 SQL，过滤掉rolname LIKE 'pg_%'系统角色 - MySQL 应查
mysql.role_edges和mysql.tables_priv，避开mysql.user表（含密码字段） - 导出后务必人工删掉
SET PASSWORD FOR、ALTER USER ... IDENTIFIED BY等敏感行
权限模板里硬编码用户名会导致迁移失败
模板本质是可复用的 SQL 片段，一旦写死 TO 'alice'@'localhost'，就只能给 alice 用。上线前还得全局替换，容易漏改或误改其他同名变量。
- 用占位符代替：比如
TO '<username>'@'<host>'</host></username>，配合脚本替换（sed "s/<username>/bob/g"</username>） - PostgreSQL 模板中避免用
current_user或session_user—— 它们在执行时才解析，无法预判效果 - MySQL 模板中慎用通配符主机名（如
'%'），生产环境应明确限定'10.20.30.%'或域名，否则模板一跑就开全网权限
执行模板前没验证角色依赖顺序会报错
比如模板里先写 GRANT analyst_role TO new_user，但 analyst_role 还没被 CREATE ROLE 定义，MySQL 报 ERROR 1396 (HY000): Operation GRANT failed for 'analyst_role'@'%'，PostgreSQL 报 role "analyst_role" does not exist。
- 模板语句必须按依赖拓扑排序：先
CREATE ROLE，再GRANT权限给角色，最后GRANT角色给用户 - 用
psql -c "SELECT rolname FROM pg_roles ORDER BY oid;"可辅助判断创建顺序（oid 小的通常更早存在） - 自动化部署时加
set -e和简单检查：执行前先SELECT 1 FROM pg_roles WHERE rolname = 'target_role';
实际落地时，最常被跳过的一步是清理模板里的注释和空行 —— 某些旧版 MySQL 客户端会把 -- 注释后换行 当成语句结束，导致后续 GRANT 被截断。模板不是写完就能跑，得当真实 SQL 文件一样过一遍语法校验。
