必须用left join而非inner join拉菜单，因为需保留所有用户基本信息（如user_id、username），即使其无任何菜单权限；若用inner join，未分配菜单的用户将被完全过滤，导致登录后菜单栏空白且难以排查。
为什么用 LEFT JOIN 而不是 INNER JOIN 拉菜单？
因为用户可能没被分配任何菜单权限，但系统仍需返回该用户基本信息（如 user_id、username），再附上空菜单项——这得靠 LEFT JOIN 保证左表（users）记录不丢失。若用 INNER JOIN，没权限的用户直接查不到，登录后菜单栏空白却无报错，排查时容易误判前端问题。
典型结构是：用户表 users → 角色表 roles → 权限关联表 role_menus → 菜单表 menus。中间至少两层 JOIN，别漏掉 role_menus 这个桥接表。
- 必须显式指定
ON条件，尤其注意role_menus.menu_id = menus.id别写成= users.id - 如果菜单有层级（
parent_id），排序时加ORDER BY menus.sort_order, menus.parent_id，否则前端渲染顺序错乱 -
menus.status = 1这类启用开关务必加在ON子句里（不是WHERE），否则LEFT JOIN会退化为INNER JOIN
如何避免 JOIN 后重复菜单项？
一个用户属于多个角色，而不同角色配置了相同菜单，直接 JOIN 会把同一菜单拉出多条——前端去重成本高，还可能影响排序稳定性。根本解法是用 DISTINCT + 合理字段组合。
只选必要字段：比如 menus.id、menus.name、menus.path、menus.icon。别带 roles.name 或 role_menus.created_at 这类会导致去重失效的字段。
- 如果必须保留角色信息（如标注“来自管理员角色”），改用
GROUP BY menus.id+STRING_AGG(roles.name, ',')（PostgreSQL）或GROUP_CONCAT(roles.name)（MySQL） - MySQL 8.0+ 可用
ROW_NUMBER() OVER (PARTITION BY menus.id ORDER BY roles.priority DESC)先筛最高优先级角色，再外层过滤rn = 1 - 别依赖前端 JS 去重：后端数据量大时，传输和解析开销明显，且分页逻辑易出错
WHERE 条件该放 JOIN 里还是最后？
用户状态、菜单启用状态、角色是否有效——这些过滤条件的位置直接影响结果集大小和性能。原则：能塞进 ON 的尽量塞，尤其是关联表的业务状态字段。
例如查指定用户 user_id = 123 的菜单，这个条件必须放在最外层 WHERE；但 menus.is_hidden = 0 和 roles.deleted_at IS NULL 应写在对应 ON 子句里，避免先全量 JOIN 再过滤。
- 错误写法：
LEFT JOIN role_menus ON role_menus.role_id = roles.id WHERE role_menus.deleted_at IS NULL—— 这会让 LEFT JOIN 失效 - 正确写法：
LEFT JOIN role_menus ON role_menus.role_id = roles.id AND role_menus.deleted_at IS NULL - MySQL 中
STRAIGHT_JOIN强制连接顺序有时能提速，但需 EXPLAIN 验证，别盲目加
MySQL vs PostgreSQL 在 NULL 处理上的坑
菜单字段（如 component、redirect）允许为 NULL，但 PostgreSQL 对 NULL = NULL 返回 UNKNOWN，导致某些 CASE 表达式或排序异常；MySQL 默认宽松些。这点在动态拼接路由时特别关键。
- 排序时用
ORDER BY menus.sort_order NULLS LAST（PostgreSQL），MySQL 用ORDER BY IFNULL(menus.sort_order, 999) - 判断菜单是否可访问，别写
menus.component != NULL，统一用menus.component IS NOT NULL - PostgreSQL 中
COALESCE(menus.icon, 'default-icon')更安全；MySQL 用IFNULL(menus.icon, 'default-icon')
跨数据库移植时，LEFT JOIN 逻辑本身一致，但 NULL 比较和字符串聚合函数差异最常引发线上菜单缺失问题。
