简介：本资源是一套基于Qt框架开发的权限管理系统源码，面向学习C++与Qt桌面开发、需要理解权限控制模型的学生和开发者。项目同时提供图形界面与命令行两种交互方式，覆盖用户登录注销、读写更新删除等权限的授权与回收、对象列表查看、用户权限信息展示、权限链式查询、清屏及命令提示等核心功能，适合作为课程设计、毕业设计或权限管理模块的参考实现。压缩包共94个文件，约805KB，以19个cpp源文件、16个头文件、6个ui界面文件和29个png截图为主，另含pro、vcxproj、sln等工程配置及若干说明文档，同时提供Qt与Visual Studio两套工程，便于直接编译运行和二次开发。目前已有131人学习下载。通过阅读源码，读者可掌握Qt界面与业务逻辑分离、权限数据结构设计、MD5加密及链式权限查询等实现思路，并借助截图与说明快速理解系统运行效果。
1. 从一份 Qt 权限管理源码说起：它到底能解决什么
很多做桌面端管理软件的同行都遇到过这种局面：项目要加登录、角色、菜单权限，第一反应是找一套现成的权限管理系统源码来改。搜到一份基于 Qt 框架的权限管理系统源码，下载下来打开 Qt Creator，编译能过，界面能跑，但接下来就卡住了——数据库表怎么设计的、权限校验在哪一层做的、菜单和按钮的权限怎么联动、换一套业务字段要动哪些文件，全得自己啃。这份源码的价值不在于它多完整，而在于它把「Qt 桌面端 + 权限模型 + 数据库」这条链路跑通了，你可以把它当成一个可运行的骨架，而不是一个成品。
这篇文章面向三类人：一是刚接触 Qt 开发、想找一个带完整业务逻辑的练手项目；二是手里有桌面管理软件、需要快速补上权限模块的工程师；三是想评估这套源码值不值得投入时间二次开发的技术负责人。我会按「权限模型怎么落地 → 数据库和 Qt 怎么对接 → 界面权限怎么控制 → 编译发布踩什么坑 → 怎么扩展成自己的系统」这条线讲清楚，每一步都给出可复现的做法和参数说明。Qt 的跨平台特性让这套东西在 Windows、Linux 甚至树莓派上都能跑，但跨平台带来的编译和插件问题也是翻车重灾区，后面会专门讲。
2. 权限模型先立住：RBAC 在 Qt 桌面端怎么落地
2.1 为什么桌面端权限管理不能照搬 Web 那套
Web 端的权限管理通常围绕 HTTP 请求做拦截，一个中间件就能把未授权的接口挡掉。Qt 桌面端没有请求这个概念，用户直接操作的是窗口、菜单、按钮、表格行，权限校验必须下沉到控件级别。常见做法是采用 RBAC 模型，但落地时要解决三个问题：用户登录后如何加载权限、权限数据如何在界面初始化时生效、运行时动态改权限怎么刷新。
我一般会把权限粒度分成三层：模块级（能不能进某个功能页）、操作级（能不能点新增/删除/导出）、数据级（能不能看到某条记录）。这份源码通常至少实现了前两层，数据级权限往往需要自己补。RBAC 的核心表就五张：用户表、角色表、权限表、用户角色关联表、角色权限关联表。不要一上来就搞部门、岗位、数据范围，先把这五张表跑通，后面扩展才有地基。
2.2 五张核心表的设计与字段说明
下面这套表结构是我在多个 Qt 管理系统中反复用过的版本，字段命名偏保守，方便和 Qt 的 QSqlTableModel 直接对接。
-- 用户表：只存认证信息，业务信息另开表 CREATE TABLE sys_user ( user_id INTEGER PRIMARY KEY AUTOINCREMENT, user_name VARCHAR(64) NOT NULL UNIQUE, password VARCHAR(128) NOT NULL, -- 存哈希，不要存明文 real_name VARCHAR(64), status INTEGER DEFAULT 1, -- 1启用 0禁用 create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 角色表 CREATE TABLE sys_role ( role_id INTEGER PRIMARY KEY AUTOINCREMENT, role_name VARCHAR(64) NOT NULL UNIQUE, role_code VARCHAR(64) NOT NULL UNIQUE, -- 代码里用 code 判断，不用中文名 remark VARCHAR(255) ); -- 权限表：用树形结构存菜单和按钮 CREATE TABLE sys_permission ( perm_id INTEGER PRIMARY KEY AUTOINCREMENT, parent_id INTEGER DEFAULT 0, perm_name VARCHAR(64) NOT NULL, perm_code VARCHAR(128) NOT NULL UNIQUE, -- 如 user:add、user:delete perm_type INTEGER NOT NULL, -- 1菜单 2按钮 path VARCHAR(255), -- 菜单对应的界面标识 sort_order INTEGER DEFAULT 0 ); -- 用户角色关联 CREATE TABLE sys_user_role ( user_id INTEGER NOT NULL, role_id INTEGER NOT NULL, PRIMARY KEY (user_id, role_id) ); -- 角色权限关联 CREATE TABLE sys_role_permission ( role_id INTEGER NOT NULL, perm_id INTEGER NOT NULL, PRIMARY KEY (role_id, perm_id) );逻辑说明：perm_code是整套系统的关键，界面里判断权限只认这个字符串，不认中文名，也不认 perm_id。原因是 perm_id 在不同环境可能不一致，而 code 是稳定的。perm_type区分菜单和按钮，菜单用于生成左侧导航，按钮用于控制控件显隐。path字段存界面类的标识，登录后根据用户拥有的菜单权限动态构建导航栏。
参数说明：password字段长度给到 128 是为了容纳 SHA-256 加盐后的十六进制字符串。status用整数而不是布尔，方便以后扩展更多状态。sort_order决定菜单显示顺序，不要依赖插入顺序。
2.3 登录后加载权限的最小实现
登录成功后不要只存一个 user_id 就完事，要把当前用户的权限 code 集合缓存起来。我一般用一个单例类PermissionManager持有QSet<QString>，登录时一次性查出来。
// PermissionManager.h class PermissionManager { public: static PermissionManager& instance(); void loadPermissions(int userId); bool hasPermission(const QString& code) const; QSet<QString> menuPermissions() const; private: QSet<QString> m_codes; QSet<QString> m_menuCodes; }; // 加载逻辑 void PermissionManager::loadPermissions(int userId) { m_codes.clear(); m_menuCodes.clear(); QSqlQuery query; query.prepare( "SELECT p.perm_code, p.perm_type FROM sys_permission p " "JOIN sys_role_permission rp ON p.perm_id = rp.perm_id " "JOIN sys_user_role ur ON rp.role_id = ur.role_id " "WHERE ur.user_id = ?"); query.addBindValue(userId); if (!query.exec()) { qWarning() << "load permissions failed:" << query.lastError().text(); return; } while (query.next()) { QString code = query.value(0).toString(); int type = query.value(1).toInt(); m_codes.insert(code); if (type == 1) m_menuCodes.insert(code); } }逻辑说明：这条 SQL 一次关联三张表，把用户所有角色的权限合并去重。用QSet而不是QList，因为权限判断是高频操作，哈希查找比线性遍历快得多。menuPermissions()单独返回菜单权限，用于构建导航栏。
参数说明：userId从登录会话中取，不要从界面控件里拿。perm_type == 1的判断要和数据库里的定义严格一致，改了一处就要改另一处，建议用枚举常量而不是魔法数字。
3. Qt 与数据库对接：QSqlDatabase 的配置与常见翻车点
3.1 选 SQLite 还是 MySQL：桌面端的现实选择
这份源码大概率用的是 SQLite，因为 Qt 自带 SQLite 驱动，不需要额外安装数据库服务，拷贝一个 exe 就能跑。但如果你的系统要多人共用一套数据，SQLite 的文件锁机制会成为瓶颈。我的判断标准很简单：单机单用户或单机多用户只读，用 SQLite；多台机器同时写，用 MySQL 或 PostgreSQL。
Qt 连接 MySQL 需要对应的驱动插件，Windows 下通常是qsqlmysql.dll，Linux 下是libqsqlmysql.so。这个驱动经常和 Qt 版本不匹配，报错信息就是热词里常见的cannot mix incompatible qt library或者could not find the qt platform plugin。根因是 Qt 的插件机制要求驱动和 Qt 核心库的版本、编译器、架构完全一致。
3.2 数据库初始化的标准流程
不管用哪种数据库，初始化流程要固定成四步：加载驱动、设置连接参数、打开连接、执行建表脚本。下面这段代码可以直接抄。
bool initDatabase(const QString& dbPath) { QSqlDatabase db = QSqlDatabase::addDatabase("QSQLITE"); db.setDatabaseName(dbPath); if (!db.open()) { qCritical() << "open database failed:" << db.lastError().text(); return false; } QSqlQuery query(db); // 开启外键约束，SQLite 默认关闭 query.exec("PRAGMA foreign_keys = ON"); // 建表语句按顺序执行 QStringList ddl = { createUserTable, createRoleTable, createPermissionTable, createUserRoleTable, createRolePermissionTable }; for (const QString& sql : ddl) { if (!query.exec(sql)) { qCritical() << "exec ddl failed:" << query.lastError().text(); return false; } } return true; }逻辑说明：addDatabase的第二个参数是连接名，默认连接叫qt_sql_default_connection。如果你需要多个连接，必须给不同的连接名，否则后一个会覆盖前一个。PRAGMA foreign_keys = ON这行很容易漏，SQLite 默认不强制外键，漏了之后删角色不会级联清理关联表，留下脏数据。
参数说明：dbPath建议放在QStandardPaths::AppDataLocation下，不要放在程序目录，否则安装到 Program Files 后没有写权限。建表语句用CREATE TABLE IF NOT EXISTS，避免重复初始化报错。
3.3 用 QSqlTableModel 还是手写 QSqlQuery
新手容易纠结这个问题。我的经验是：简单的单表增删改查用QSqlTableModel配QTableView，十分钟就能出一个列表页；涉及多表关联、权限过滤、复杂查询的，老老实实手写QSqlQuery。QSqlTableModel的setFilter只支持简单的 WHERE 条件，做不了 JOIN。
还有一个坑：QSqlTableModel默认的OnManualSubmit策略下，修改后不调用submitAll()不会写库，界面上看着改了，重启就没了。这个玄学问题坑过不少人，排查半天以为是数据库没提交，其实是模型策略没设对。
4. 界面权限控制：菜单、按钮和运行时刷新
4.1 根据权限动态生成左侧菜单
登录成功后，主窗口不应该把所有菜单都创建好再隐藏，而是根据menuPermissions()动态构建。这样做的好处是权限变更后重新登录就能生效，不需要改代码。
void MainWindow::buildMenu() { auto& pm = PermissionManager::instance(); QList<QPair<QString, QString>> menuDefs = { {"system:user", "用户管理"}, {"system:role", "角色管理"}, {"system:perm", "权限管理"}, {"biz:order", "订单管理"} }; for (const auto& def : menuDefs) { if (!pm.hasPermission(def.first)) continue; QAction* act = new QAction(def.second, this); act->setData(def.first); connect(act, &QAction::triggered, this, &MainWindow::onMenuClicked); ui->menuBar->addAction(act); } }逻辑说明：菜单定义用QList<QPair>硬编码在代码里，而不是从数据库读。原因是菜单的层级和图标资源在代码里更可控，数据库只存权限 code。hasPermission判断不通过就直接跳过，不创建控件，减少内存占用。
参数说明：def.first必须和数据库perm_code完全一致，大小写敏感。setData把 code 挂在 Action 上，点击时通过sender()->data()取出来，避免再写一遍映射。
4.2 按钮级权限的三种控制方式
按钮权限比菜单细，常见做法有三种：隐藏、禁用、点击时拦截。隐藏适合普通用户完全不该看到的操作；禁用适合需要让用户知道有这个功能但当前无权使用；点击时拦截适合权限可能动态变化的场景。
我一般封装一个工具函数，在界面初始化时统一处理：
void applyButtonPermission(QWidget* root, const QString& permCode, QWidget* target) { if (!PermissionManager::instance().hasPermission(permCode)) { target->setVisible(false); // 或者 target->setEnabled(false); } }逻辑说明：root参数用于以后扩展成递归查找子控件。target直接传按钮指针，比按 objectName 查找更可靠，因为 objectName 容易在 Designer 里被改掉。
参数说明：如果选择禁用而不是隐藏，记得在按钮的 tooltip 里说明原因，否则用户会以为是 bug。这个细节在验收时经常被提。
4.3 运行时权限变更怎么刷新
管理员在权限管理界面改了某个角色的权限，当前登录用户如果是这个角色，界面不会自动刷新。常见做法是改完后弹窗提示「权限已变更，请重新登录」，然后调用qApp->quit()或跳回登录页。不要试图做无刷新热更新，Qt 的界面状态太复杂，容易出诡异问题。
如果一定要做，我的做法是发一个全局信号permissionsChanged()，主窗口收到后重建菜单栏和工具栏，已经打开的窗口不处理，提示用户关闭重开。这个方案能覆盖 90% 的场景，剩下的 10% 是打开着的对话框里的按钮权限，只能靠重新打开对话框解决。
5. 编译、发布与跨平台避坑记录
5.1 现象：编译时报 cannot find -lpublic 或 unknown module
原因：.pro文件里写了QT += webenginewidgets之类的模块，但当前 Qt 安装没有这个模块，或者模块名拼写不对。Qt 6 之后很多模块被拆分或改名，比如webenginewidgets需要单独安装 Qt WebEngine 组件。
解决：打开 Qt Maintenance Tool，确认对应模块已安装。如果是 Qt 6，检查模块名是否变成了webenginewidgets以外的名字。cannot find -lpublic通常是第三方库的链接名写错，检查LIBS += -L路径 -l库名里的库名是否和实际文件名匹配，Windows 下是.lib，Linux 下是.so。
5.2 现象：运行时报 could not find the qt platform plugin
原因：发布时只拷贝了 exe，没有拷贝 Qt 的平台插件目录platforms。Windows 下需要qwindows.dll，Linux 下需要libqxcb.so，嵌入式 Linux 下可能是linuxfb或eglfs。
解决：用windeployqt（Windows）或linuxdeployqt（Linux）自动拷贝依赖。如果手动拷贝，确保platforms目录和 exe 在同一级。嵌入式环境要设置QT_QPA_PLATFORM=linuxfb或对应值，这个环境变量在 systemd 服务里要显式声明，否则服务启动时找不到显示后端。
5.3 现象：程序在开发机正常，到客户机崩溃报 0000005
原因：访问违例，常见于空指针、数组越界、跨线程操作 UI。Qt 的信号槽如果用了Qt::DirectConnection跨线程，槽函数里操作 UI 就会崩。另一个常见原因是数据库查询返回空结果，代码没判断query.next()就直接取value()。
解决：用Q_ASSERT和日志把崩溃点定位到具体行。跨线程一律用Qt::QueuedConnection，UI 操作只在主线程做。数据库取值前必须判断query.isValid()。发布版本打开崩溃转储，Windows 下配SetUnhandledExceptionFilter，Linux 下配 core dump，能省很多排查时间。
5.4 现象：Qt 版本混用导致 cannot mix incompatible qt library
原因：系统里装了多个 Qt 版本，运行时加载了错误版本的库。比如开发用 Qt 5.15.2，客户机上有 Qt 5.12 的库在 PATH 里，加载顺序不对就报这个。
解决：发布时把 Qt 库和插件一起打包，用rpath（Linux）或同目录优先（Windows）确保加载的是自己带的库。Linux 下用patchelf --set-rpath '$ORIGIN/lib'设置相对路径。不要依赖系统 Qt，哪怕客户机装过 Qt 也不要依赖。
5.5 现象：树莓派上交叉编译 Qt 后界面显示异常
原因：树莓派的 GPU 驱动和 Qt 的 EGLFS 后端不匹配，或者交叉编译时用的 sysroot 和板子上的库版本不一致。
解决：先确认板子上的 Qt 版本和交叉编译工具链的版本一致。显示后端优先试linuxfb，它不依赖 GPU，兼容性最好，缺点是性能差。如果必须用 EGLFS，检查/dev/dri/card0权限和QT_QPA_EGLFS_INTEGRATION环境变量。交叉编译时把板子的/usr/lib和/usr/include完整同步到 sysroot，不要只拷部分库。
6. 把这套源码改成自己的系统：扩展点与验证方法
拿到一份 Qt 权限管理源码，直接改业务字段是最低效的做法。我的习惯是先做三件事：跑通登录到菜单的完整链路、找到权限判断的唯一入口、确认数据库初始化的位置。这三件事定位清楚了，后面加功能就是填空。
扩展新业务模块的标准步骤是这样的。第一步，在sys_permission表里插入新模块的菜单和按钮权限，perm_code按模块:操作命名，比如device:list、device:add、device:export。第二步，在MainWindow::buildMenu的menuDefs里加一行菜单定义，code 和数据库一致。第三步，新建业务界面类，在构造函数里对每个按钮调用applyButtonPermission。第四步，业务表的增删改查单独建表，不要往sys_user里塞业务字段。
验证权限是否真正生效，不能只看界面。我一般用三个测试用例：用管理员登录，确认所有菜单和按钮可见可用；用一个只有查看权限的角色登录，确认新增删除按钮不可见，且直接调用对应槽函数也不会执行；在数据库里手动删掉某个权限关联，重新登录确认菜单消失。第三个用例最关键，它能验证权限判断不是写死在界面里的。
还有一个容易被忽略的点：权限判断要放在业务逻辑层，不能只放在界面层。界面隐藏了按钮，但如果有其他入口能触发同一个槽函数，权限就形同虚设。我的做法是在槽函数开头再判断一次hasPermission，不通过直接 return 并记录日志。这样即使界面层漏了，业务层也能兜住。
最后说一个我踩过的坑：不要用perm_id做界面判断。早期图省事，菜单 Action 的 data 存的是 perm_id，结果换了一套数据库，id 变了，权限全乱。后来统一改成 perm_code，再也没出过这个问题。源码里的表结构如果用的是 id 判断，建议第一时间改掉，这个改动越早做成本越低。希望帮到你。
本文还有配套的精品资源，点击获取
