我的本职工作是区图书馆的图书管理员日常业务就是跟图书借还、读者办证、馆内盘点打交道。听起来跟写代码八竿子打不着但2024年夏天馆里旧系统频繁罢工之后我决定自己用PHP手搓一套带多角色权限的管理系统。这套系统最后不仅真跑起来了还被全馆上下用了大半年连隔壁文化馆都来打听能不能复刻一套。这篇文章就是完整的过程实录包括我最开始的设计失误、权限模型的推倒重来、上线前的各种奇葩踩坑以及最终稳定运行的配置方案。如果你也是非科班出身、正在纠结用PHP写管理系统到底行不行多角色权限该怎么做或者手头恰好有一个小单位的内部系统想自己折腾一下这篇应该能给你不少能直接落地的参考。1. 图书管理员为什么非要自己写一套管理系统1.1 馆里的旧系统到底哪里让人崩溃旧系统是2014年某家小公司做的B/S架构管理系统UI是那种灰底蓝字的经典配色每次登录都要输入一个固定的账号密码全馆所有工作人员共用一个号。表面上每个人都有工号但实际系统里只有三种状态管理员、普通工作人员、啥都干不了只能看的人。问题在于这个管理员权限是死的谁登录了谁就是管理员。最让我崩溃的场景是这样的我在采编室做新书入库需要在系统里录入ISBN、分类号、馆藏位置同时要审核采购单隔壁借阅台的同事只想查读者信息和办借还书她根本不需要看到采购审核那些按钮。旧系统把所有菜单都平铺在左侧点进去没有权限拦截只是提交数据时会报无权限操作。这种设计导致新来的实习生误点过两次批量删除馆藏虽然最后靠数据库备份恢复但那次之后馆领导就念叨着要换系统。换个商业系统要十几万预算报上去就被打回来了。我当时手里正好有一本《细说PHP》和一门Udemy的特价课程加上馆里那台淘汰的旧服务器闲着也是闲着就动了干脆自己写一个的念头。1.2 为什么选PHP而不是Java或Python很多人劝我学Spring Boot或者用Django理由很充分生态成熟、招人容易、后期扩展方便。但我的实际约束条件摆在这里旧服务器配置很拉胯4核心CPU、8G内存跑Java的JVM加上Spring Boot那套依赖光启动就吃力我只有一台Windows Server 2012没有专门的Linux运维经验PHPApacheMySQL的集成环境用的就是phpStudy那种一键包对我来说最友好管理系统的核心需求是增删改查和权限控制PHP原生开发完全覆盖得了不需要微服务那套重武器我自己学PHP是跟着网课走从变量、数组、函数到PDO操作数据库三个月能上手换成Java光是配置Maven和Spring的注解就要多学好几周另外PHP在Web开发里有一个被很多人忽视的优势——改完刷新就能看到效果没有编译这一道工序。对边学边写的业余开发者来说这个反馈速度太重要了。我在写借书流程时改一个逻辑错误F5刷新页面就能立刻验证大大缩短了试错周期。1.3 为什么坚持手搓而不是上框架说实话用Laravel或ThinkPHP做这套系统会更省事路由、ORM、中间件都现成的。但我当时的考虑是这样的一是我没有Composer和框架的实战基础与其花时间学框架的约定不如先把原生PHP的语法和逻辑练扎实。二是这套系统的业务其实不复杂核心表就六张用户表、角色表、权限表、角色权限关联表、图书表、借阅记录表。Laravel的Eloquent虽然方便但为了一个小项目引入整个框架后期维护成本并不比原生低。三是手搓能让我真正理解权限校验的原理。框架的中间件帮你做了所有事但出了问题你不知道它在哪一环挂的。我自己写Session校验、写角色权限判断虽然代码丑但每一行逻辑都清楚。等系统稳定跑通之后我才回头看ThinkPHP的文档发现我手搓的MVC结构和路由分发跟框架里那套本质上是同一个思路。也就是说手搓一遍之后再上框架理解成本会低很多。2. 第一版权限设计是怎么翻车的以及最终的角色模型长什么样2.1 我最开始的三板斧用户表加个role字段拿到需求后我第一反应是给用户表加一个role字段值就三种admin馆长和系统管理员、staff工作人员、reader读者自助查询。然后登录的时候把这个角色值存进Session页面里用 if ($_SESSION[role] admin) 来控制菜单显示和操作按钮。这套简单方案跑了两个星期就漏出问题了。最典型的一个场景借阅台的A同事因为业务能力好馆长给了她一部分采编审核的权限但她不该有采购单管理的权限。在我的单角色字段设计下她要么被归类为staff不能审核要么就得给一个独立的角色。只要权限组合一多role字段根本没法表达。另一个问题是代码里到处是 if 判断从登录控制器到每个业务方法的开头都有一大坨 if ($_SESSION[role] staff || $_SESSION[role] admin)写着写着就乱套了。有次我改借书逻辑漏了一个if判断理论上任何人都能调用借书接口把馆藏图书借到任何读者名下。虽然只是内部系统没造成实际损失但这个教训让我彻底意识到权限设计不能这么儿戏。2.2 角色和权限拆开RBAC模型的引入我后来在PHP社区逛帖时看到有老哥提到RBACRole-Based Access Control基于角色的访问控制核心思想就一句话用户不直接绑定权限而是通过角色来获得权限。具体拆成三张核心表user用户表字段包括id、username、password_hash、real_name、role_id、is_active、created_atrole角色表字段包括id、role_name、role_code、descriptionpermission权限表字段包括id、perm_name、perm_code、module、description再加上一张关联表 role_permission把角色和权限多对多关联起来。用户表里的role_id不是直接决定能干什么而是通过role_permission表间接决定。这个模型一落地我之前的痛点就解决了借阅台的A同事需要采编审核权限我只需要新建一个角色比如采编助理给它分配采编审核和图书查询权限再把A的role_id指向它。馆长需要跨模块管理就建超级管理员角色权限全勾上。2.3 权限表里到底该放哪些权限点这一步是最容易被忽略的。很多人建了RBAC表结构但权限点收得特别粗比如图书记录管理这一个权限点把增删改查全包了那跟单角色字段也没区别。我实际在permission表里设计权限点时参考了模块和操作的二维矩阵图书模块book_view查看书库、book_add新增图书、book_edit编辑图书信息、book_delete下架或删除图书、book_import批量导入借阅模块borrow_create办理借书、borrow_return办理还书、borrow_renew续借、borrow_query查询借阅记录读者模块reader_view查看读者信息、reader_add新增读者、reader_edit编辑读者、reader_deactivate注销读者系统模块user_manage用户管理、role_manage角色管理、perm_manage权限配置、log_view查看操作日志这套权限点设计的好处是后期给某个角色分配权限时可以细到只能还书不能借书这种粒度。比如对临时工角色我们只给reader_view和borrow_return借书权限不给因为临时工主要负责收书入库。2.4 权限判断的代码实现系统里我封装了一个权限检查函数放在一个公共文件里function check_permission($perm_code) { if (empty($_SESSION[user_id])) { header(Location: /login.php); exit; } $role_id $_SESSION[role_id]; // 超级管理员直接放行不用走权限表查询 if ($role_id 1) { return true; } // 查角色权限关联表 $pdo get_db_connection(); $stmt $pdo-prepare(SELECT COUNT(*) FROM role_permission rp INNER JOIN permission p ON rp.permission_id p.id WHERE rp.role_id ? AND p.perm_code ?); $stmt-execute([$role_id, $perm_code]); return $stmt-fetchColumn() 0; }在具体业务方法里比如处理借书操作if (!check_permission(borrow_create)) { die(没有借书操作权限请联系管理员); }页面菜单的显示也走同样一套菜单表里每个菜单项绑定一个perm_code渲染侧边栏时逐项检查。这样A同事登录后看到的菜单就是她被授权的那些模块不会出现点了按钮才报错的情况。提示check_permission函数里我把role_id为1的超级管理员直接放行了这是一个典型的后门设计。实际使用中要保证系统中至少存在一个role_id1的角色并且不要轻易把用户绑定到这个角色上。3. 核心功能从0到1登录、会话、密码安全这些躲不掉的细节3.1 登录逻辑与密码存储别再用md5了我第一版登录代码里用的是md5(md5($password))这种双重哈希后来查资料才知道这种做法在2024年已经不推荐了。PHP官方推荐的password_hash()和password_verify()才是正道// 注册或创建用户时密码加密存储 $hashed password_hash($password, PASSWORD_DEFAULT); // 登录验证时 if (password_verify($input_password, $row[password_hash])) { // 验证通过建立会话 }password_hash默认用的算法是bcrypt还可以在cost参数里控制计算代价。我在测试环境试过cost12时一次验证大概要80毫秒对内网系统完全可以接受但暴力破解的难度会高很多。password_verify是专门用来配合password_hash的它会自动从哈希串里读取salt和cost信息不需要你额外管理盐值。有一点要注意PASSWORD_DEFAULT这个算法会随PHP版本升级而更新所以password_hash生成的哈希串长度可能不一样。数据库里的password_hash字段我设计的是varchar(255)就是为了给未来算法升级留足空间。3.2 会话管理与登录状态保持PHP默认的Session会有一些安全上的坑我在上线前专门处理了几个session_start()之前不能有任何输出否则会报headers already sent错误这个坑新手必踩登录成功后要调用session_regenerate_id(true)防止会话固定攻击把用户ID、用户名、角色ID这些关键信息存Session但不要存密码哈希设置Session过期时间图书馆的电脑经常被不同人用人走忘了退出是个大问题我的做法是登录成功后设置一个最后的活跃时间戳每次请求时检查超时$_SESSION[last_active] time(); $timeout 1800; // 30分钟无操作自动退出 if (time() - $_SESSION[last_active] $timeout) { session_unset(); session_destroy(); header(Location: /login.php?msgtimeout); exit; }这套逻辑虽然不复杂但对图书馆这种场景非常重要。馆员经常去书架间找书电脑放着不管如果不自动退出路过的读者就可能操作后台。加了超时之后这个风险就基本消除了。3.3 图书CRUD与检索PDO预处理到底防住了什么图书管理的主流程是新增书目→贴条码→上架→读者借阅→归还核心操作都是围绕图书记录表展开的。我在写图书新增功能时一开始直接用字符串拼接SQL$sql INSERT INTO books (title, isbn, author, category, location) VALUES ($title, $isbn, $author, $category, $location);这要是有人在前端表单里输入一条 ; DROP TABLE books; --那就是灾难。我后来全部改成PDO预处理用占位符传参$stmt $pdo-prepare(INSERT INTO books (title, isbn, author, category, location) VALUES (?, ?, ?, ?, ?)); $stmt-execute([$title, $isbn, $author, $category, $location]);预处理的好处是参数和SQL语句分开发送到数据库参数只作为数据被处理不会变成SQL指令的一部分。这个不是PHP特有的技巧是数据库层面的功能但PDO让使用变得很简单。图书检索我用了最简单但好用的方式关键词LIKE匹配加分类筛选。用SQL拼一个动态条件注意每一段都用预处理参数$conditions []; $params []; if (!empty($keyword)) { $conditions[] (title LIKE ? OR author LIKE ? OR isbn LIKE ?); array_push($params, %$keyword%, %$keyword%, %$keyword%); } if (!empty($category)) { $conditions[] category ?; $params[] $category; } $where_sql $conditions ? (WHERE . implode( AND , $conditions)) : ; $stmt $pdo-prepare(SELECT * FROM books $where_sql ORDER BY created_at DESC); $stmt-execute($params);这种方式唯一的性能瓶颈是LIKE %keyword% 会导致全表扫描但馆藏也就几万册加上索引后查询基本都在几十毫秒以内。如果未来书库量涨到几十万本那就得上全文索引或考虑MySQL的全文搜索了当前阶段用不着。4. 上线前踩过的坑PHP常见错误、中文乱码和序列化问题4.1 白屏之痛从页面啥都不显示到看错误日志开发过程中我遇到最多的就是白屏。页面访问后一片空白什么错误信息都没有。第一反应是代码写错了但不知道错在哪。后来才发现PHP的display_errors默认在生产环境是关闭的所有错误都被写进日志里而你什么都看不到。解决办法分两步。开发阶段在入口文件顶部开启错误显示ini_set(display_errors, 1); ini_set(display_startup_errors, 1); error_reporting(E_ALL);上线后肯定不能把错误直接显示给用户但也不能完全隐藏正确做法是配置日志记录。我用的是phpStudy配置Apache环境变量log_errors On error_log D:/wwwlogs/php_error.log然后在公共文件里做一个自定义异常处理器和错误处理器把错误详情写进日志用户端只看到友好的系统繁忙请稍后再试。我印象最深的一个错误是我在一个函数里用了另一个文件里定义的函数但忘记包含那个文件白屏了两三个小时才通过日志定位到是undefined function的报错。从那以后我养成了一个习惯所有自定义函数文件都在入口文件里集中include_once而不是在每个业务脚本里零散包含。4.2 PHP序列化中文的坑我自己遇到的一个很实际的坑把数组存到数据库或缓存时用了序列化结果中文变成了乱码。这个现象的根本原因是seralize出来的字符串包含不可见字符和长度前缀如果存进varchar字段时没有正确设置编码或者数据库字段是latin1字符集中文就会被截断或转义成乱码。后来我改用两个方案一是序列化后base64_encode再存$data [name 中文, list [1,2,3]]; $stored base64_encode(serialize($data)); // 读取时 $restored unserialize(base64_decode($stored));二是干脆用JSON代替序列化$stored json_encode($data, JSON_UNESCAPED_UNICODE); $restored json_decode($stored, true);JSON的方式在我这个项目里更合适因为JSON字符串是文本格式可读性好字段一多不会出现奇奇怪怪的字符。如果你存的是PHP对象而且需要保留对象类型才考虑serialize加base64的方式。4.3 跨域和接口调试前台读者端和后台管理端的分离系统里读者端是一个独立的页面放在图书馆大厅的公共查询机上通过AJAX调后台接口查询馆藏图书和个人借阅记录。这里就遇到了跨域问题。公共查询机的浏览器访问的是http://192.168.1.88:8080/opac/后台管理端是http://192.168.1.88/admin/端口和路径不一样浏览器默认会拦截跨域请求。我处理的方式是在公共接口文件夹里加一个统一的响应头header(Access-Control-Allow-Origin: *); header(Access-Control-Allow-Methods: GET, POST, OPTIONS); header(Access-Control-Allow-Headers: Content-Type);如果未来要限制来源可以把改成具体的域名。注意如果请求涉及带Cookie的会话认证Access-Control-Allow-Origin不能是而必须是明确的来源还要加Access-Control-Allow-Credentials: true。我这边读者查询接口是不需要会话的所以用了宽松配置。调试的时候用Chrome的F12开发者工具看Network面板能很清楚地看到AJAX请求有没有被CORS拦截以及返回状态码和响应体。新手写接口如果遇到跨域无效优先检查响应头有没有正常输出以及是不是有PHP警告信息混在JSON响应前面导致JSON解析失败。4.4 文件包含漏洞一个容易忽略的安全隐患求助帖里经常有人遇到include $_GET[page]这样的写法然后就被利用来读取任意文件。我在写页面路由时避免了这个设计而是用白名单方式$page $_GET[page] ?? dashboard; $allowed_pages [dashboard, books, borrows, readers, roles, logs]; if (!in_array($page, $allowed_pages)) { $page dashboard; } include ./views/{$page}.php;用户能传进来的page值被限制在一个固定列表里不会变成路径穿越的入口。这个习惯后来救了我一次有同事在测试时随手在URL里输入了../config.php结果被白名单拦截返回了默认页要是没做白名单数据库账号密码可能就裸奔了。5. 从本机跑通到局域网部署让系统真正被同事们用起来5.1 环境搭建的最终配置我开发时用的是Windows上的phpStudyApachePHP 7.4MySQL 5.7组合上线部署延续了同一套环境主要原因是迁移成本最低。下面配置里有点容易忘记的部分PHP启用扩展pdo_mysql、mysqli、openssl、mbstring、curl这些在php.ini里要把前面的分号去掉Apache开启mod_rewrite模块因为我用了伪静态美化URL同时配置AllowOverride AllMySQL的字符集统一设置为utf8mb4而不是utf8因为utf8mb4才能存储四字节的emoji和一些特殊字符关闭目录列表在httpd.conf里把Options Indexes的Indexes去掉防止用户直接浏览文件目录数据库连接方面我在配置文件里维护了一个PDO单例function get_db_connection() { static $pdo null; if ($pdo null) { $dsn mysql:host127.0.0.1;dbnamelibsys;charsetutf8mb4; $options [ PDO::ATTR_ERRMODE PDO::ERRMODE_EXCEPTION, PDO::ATTR_DEFAULT_FETCH_MODE PDO::FETCH_ASSOC, PDO::ATTR_EMULATE_PREPARES false, ]; $pdo new PDO($dsn, libuser, password, $options); } return $pdo; }PDO::ATTR_EMULATE_PREPARES设为false是告诉PDO不要模拟预处理真的把预处理交给MySQL执行这样SQL注人的防护更彻底同时还能避免某些版本下LIMIT参数用预处理出错的问题。5.2 局域网访问的几个坎开发时我用127.0.0.1访问一切正常但一旦让借阅台的同事访问就遇到一堆问题。第一是防火墙拦了80端口。Windows Server自带的防火墙默认不放行外部访问80端口的流量我需要在防火墙高级设置里添加入站规则允许TCP 80端口。第二是Apache默认监听localhost如果httpd.conf里的Listen是127.0.0.1:80外部访问自然不通。改成Listen 0.0.0.0:80即可。第三是MySQL的权限。默认root账户可能只允许localhost登录PHP跑在和MySQL同一个服务器上倒是无所谓但千万别把数据库账号密码写死在页面HTML里。我用的是独立账号libuser权限只授予libsys这个库最小权限原则在数据库层面也适用。5.3 备份策略一点不夸张备份救了我的命系统跑了大概两个月后有次我执行批量更新时SQL的WHERE条件写错了一下把一百多本图书的馆藏位置全改错了。当时心里拔凉拔凉的还好我每天凌晨用计划任务自动备份数据库mysqldump -ulibuser -ppassword libsys D:\backup\libsys_%date:~0,4%%date:~5,2%%date:~8,2%.sql这行批处理在Windows计划任务里每天3点执行一次保留最近七天。数据恢复时只丢了一天的更新操作重新录入了一批当天新上架的书就行。管理员系统里我还加了一个操作日志表记录谁在什么时间改了什么数据这个在回溯问题时非常有用建议每一位自己写管理系统的朋友都加上这个表。6. 写下这套系统后我送给同样非科班的几点经验如果你也打算自己动手写一个小型管理系统我的建议是别急着找现成的框架把原生PHP这几个点吃透——PDO预处理、Session管理、RBAC权限模型、文件包含和目录安全。这些是任何管理系统都躲不掉的底层能力。还有一个心得是角色的设计一定要一开始就想清楚谁能干什么再动手。我先写代码后做权限模型导致中间重构了一次用户表和相关逻辑浪费了至少一个周末的时间。正确的顺序是先画角色和权限清单再去写登录和菜单渲染。至于外界常说的PHP已经过时之类的声音我在这个项目里没感觉到什么影响。图书馆管理系统不需要高并发不需要微服务PHP配合MySQL在局域网内跑得又快又稳定而且我这种半路出家的人维护起来几乎没有门槛。工具是否合适始终要结合自己的场景来判断的。这台旧服务器到现在还很稳系统也一直在馆里运行着。如果你也在琢磨一个类似的小项目不知道从哪里开始我的建议是找一个最痛的业务场景切入比如图书管理里的借还流程先打通一条最简单的链路再逐步加上多角色和权限控制你会发现当需求足够具体的时候技术其实没那么难。 图书管理员用PHP手搓管理系统：RBAC多角色权限设计实录
我的本职工作是区图书馆的图书管理员日常业务就是跟图书借还、读者办证、馆内盘点打交道。听起来跟写代码八竿子打不着但2024年夏天馆里旧系统频繁罢工之后我决定自己用PHP手搓一套带多角色权限的管理系统。这套系统最后不仅真跑起来了还被全馆上下用了大半年连隔壁文化馆都来打听能不能复刻一套。这篇文章就是完整的过程实录包括我最开始的设计失误、权限模型的推倒重来、上线前的各种奇葩踩坑以及最终稳定运行的配置方案。如果你也是非科班出身、正在纠结用PHP写管理系统到底行不行多角色权限该怎么做或者手头恰好有一个小单位的内部系统想自己折腾一下这篇应该能给你不少能直接落地的参考。1. 图书管理员为什么非要自己写一套管理系统1.1 馆里的旧系统到底哪里让人崩溃旧系统是2014年某家小公司做的B/S架构管理系统UI是那种灰底蓝字的经典配色每次登录都要输入一个固定的账号密码全馆所有工作人员共用一个号。表面上每个人都有工号但实际系统里只有三种状态管理员、普通工作人员、啥都干不了只能看的人。问题在于这个管理员权限是死的谁登录了谁就是管理员。最让我崩溃的场景是这样的我在采编室做新书入库需要在系统里录入ISBN、分类号、馆藏位置同时要审核采购单隔壁借阅台的同事只想查读者信息和办借还书她根本不需要看到采购审核那些按钮。旧系统把所有菜单都平铺在左侧点进去没有权限拦截只是提交数据时会报无权限操作。这种设计导致新来的实习生误点过两次批量删除馆藏虽然最后靠数据库备份恢复但那次之后馆领导就念叨着要换系统。换个商业系统要十几万预算报上去就被打回来了。我当时手里正好有一本《细说PHP》和一门Udemy的特价课程加上馆里那台淘汰的旧服务器闲着也是闲着就动了干脆自己写一个的念头。1.2 为什么选PHP而不是Java或Python很多人劝我学Spring Boot或者用Django理由很充分生态成熟、招人容易、后期扩展方便。但我的实际约束条件摆在这里旧服务器配置很拉胯4核心CPU、8G内存跑Java的JVM加上Spring Boot那套依赖光启动就吃力我只有一台Windows Server 2012没有专门的Linux运维经验PHPApacheMySQL的集成环境用的就是phpStudy那种一键包对我来说最友好管理系统的核心需求是增删改查和权限控制PHP原生开发完全覆盖得了不需要微服务那套重武器我自己学PHP是跟着网课走从变量、数组、函数到PDO操作数据库三个月能上手换成Java光是配置Maven和Spring的注解就要多学好几周另外PHP在Web开发里有一个被很多人忽视的优势——改完刷新就能看到效果没有编译这一道工序。对边学边写的业余开发者来说这个反馈速度太重要了。我在写借书流程时改一个逻辑错误F5刷新页面就能立刻验证大大缩短了试错周期。1.3 为什么坚持手搓而不是上框架说实话用Laravel或ThinkPHP做这套系统会更省事路由、ORM、中间件都现成的。但我当时的考虑是这样的一是我没有Composer和框架的实战基础与其花时间学框架的约定不如先把原生PHP的语法和逻辑练扎实。二是这套系统的业务其实不复杂核心表就六张用户表、角色表、权限表、角色权限关联表、图书表、借阅记录表。Laravel的Eloquent虽然方便但为了一个小项目引入整个框架后期维护成本并不比原生低。三是手搓能让我真正理解权限校验的原理。框架的中间件帮你做了所有事但出了问题你不知道它在哪一环挂的。我自己写Session校验、写角色权限判断虽然代码丑但每一行逻辑都清楚。等系统稳定跑通之后我才回头看ThinkPHP的文档发现我手搓的MVC结构和路由分发跟框架里那套本质上是同一个思路。也就是说手搓一遍之后再上框架理解成本会低很多。2. 第一版权限设计是怎么翻车的以及最终的角色模型长什么样2.1 我最开始的三板斧用户表加个role字段拿到需求后我第一反应是给用户表加一个role字段值就三种admin馆长和系统管理员、staff工作人员、reader读者自助查询。然后登录的时候把这个角色值存进Session页面里用 if ($_SESSION[role] admin) 来控制菜单显示和操作按钮。这套简单方案跑了两个星期就漏出问题了。最典型的一个场景借阅台的A同事因为业务能力好馆长给了她一部分采编审核的权限但她不该有采购单管理的权限。在我的单角色字段设计下她要么被归类为staff不能审核要么就得给一个独立的角色。只要权限组合一多role字段根本没法表达。另一个问题是代码里到处是 if 判断从登录控制器到每个业务方法的开头都有一大坨 if ($_SESSION[role] staff || $_SESSION[role] admin)写着写着就乱套了。有次我改借书逻辑漏了一个if判断理论上任何人都能调用借书接口把馆藏图书借到任何读者名下。虽然只是内部系统没造成实际损失但这个教训让我彻底意识到权限设计不能这么儿戏。2.2 角色和权限拆开RBAC模型的引入我后来在PHP社区逛帖时看到有老哥提到RBACRole-Based Access Control基于角色的访问控制核心思想就一句话用户不直接绑定权限而是通过角色来获得权限。具体拆成三张核心表user用户表字段包括id、username、password_hash、real_name、role_id、is_active、created_atrole角色表字段包括id、role_name、role_code、descriptionpermission权限表字段包括id、perm_name、perm_code、module、description再加上一张关联表 role_permission把角色和权限多对多关联起来。用户表里的role_id不是直接决定能干什么而是通过role_permission表间接决定。这个模型一落地我之前的痛点就解决了借阅台的A同事需要采编审核权限我只需要新建一个角色比如采编助理给它分配采编审核和图书查询权限再把A的role_id指向它。馆长需要跨模块管理就建超级管理员角色权限全勾上。2.3 权限表里到底该放哪些权限点这一步是最容易被忽略的。很多人建了RBAC表结构但权限点收得特别粗比如图书记录管理这一个权限点把增删改查全包了那跟单角色字段也没区别。我实际在permission表里设计权限点时参考了模块和操作的二维矩阵图书模块book_view查看书库、book_add新增图书、book_edit编辑图书信息、book_delete下架或删除图书、book_import批量导入借阅模块borrow_create办理借书、borrow_return办理还书、borrow_renew续借、borrow_query查询借阅记录读者模块reader_view查看读者信息、reader_add新增读者、reader_edit编辑读者、reader_deactivate注销读者系统模块user_manage用户管理、role_manage角色管理、perm_manage权限配置、log_view查看操作日志这套权限点设计的好处是后期给某个角色分配权限时可以细到只能还书不能借书这种粒度。比如对临时工角色我们只给reader_view和borrow_return借书权限不给因为临时工主要负责收书入库。2.4 权限判断的代码实现系统里我封装了一个权限检查函数放在一个公共文件里function check_permission($perm_code) { if (empty($_SESSION[user_id])) { header(Location: /login.php); exit; } $role_id $_SESSION[role_id]; // 超级管理员直接放行不用走权限表查询 if ($role_id 1) { return true; } // 查角色权限关联表 $pdo get_db_connection(); $stmt $pdo-prepare(SELECT COUNT(*) FROM role_permission rp INNER JOIN permission p ON rp.permission_id p.id WHERE rp.role_id ? AND p.perm_code ?); $stmt-execute([$role_id, $perm_code]); return $stmt-fetchColumn() 0; }在具体业务方法里比如处理借书操作if (!check_permission(borrow_create)) { die(没有借书操作权限请联系管理员); }页面菜单的显示也走同样一套菜单表里每个菜单项绑定一个perm_code渲染侧边栏时逐项检查。这样A同事登录后看到的菜单就是她被授权的那些模块不会出现点了按钮才报错的情况。提示check_permission函数里我把role_id为1的超级管理员直接放行了这是一个典型的后门设计。实际使用中要保证系统中至少存在一个role_id1的角色并且不要轻易把用户绑定到这个角色上。3. 核心功能从0到1登录、会话、密码安全这些躲不掉的细节3.1 登录逻辑与密码存储别再用md5了我第一版登录代码里用的是md5(md5($password))这种双重哈希后来查资料才知道这种做法在2024年已经不推荐了。PHP官方推荐的password_hash()和password_verify()才是正道// 注册或创建用户时密码加密存储 $hashed password_hash($password, PASSWORD_DEFAULT); // 登录验证时 if (password_verify($input_password, $row[password_hash])) { // 验证通过建立会话 }password_hash默认用的算法是bcrypt还可以在cost参数里控制计算代价。我在测试环境试过cost12时一次验证大概要80毫秒对内网系统完全可以接受但暴力破解的难度会高很多。password_verify是专门用来配合password_hash的它会自动从哈希串里读取salt和cost信息不需要你额外管理盐值。有一点要注意PASSWORD_DEFAULT这个算法会随PHP版本升级而更新所以password_hash生成的哈希串长度可能不一样。数据库里的password_hash字段我设计的是varchar(255)就是为了给未来算法升级留足空间。3.2 会话管理与登录状态保持PHP默认的Session会有一些安全上的坑我在上线前专门处理了几个session_start()之前不能有任何输出否则会报headers already sent错误这个坑新手必踩登录成功后要调用session_regenerate_id(true)防止会话固定攻击把用户ID、用户名、角色ID这些关键信息存Session但不要存密码哈希设置Session过期时间图书馆的电脑经常被不同人用人走忘了退出是个大问题我的做法是登录成功后设置一个最后的活跃时间戳每次请求时检查超时$_SESSION[last_active] time(); $timeout 1800; // 30分钟无操作自动退出 if (time() - $_SESSION[last_active] $timeout) { session_unset(); session_destroy(); header(Location: /login.php?msgtimeout); exit; }这套逻辑虽然不复杂但对图书馆这种场景非常重要。馆员经常去书架间找书电脑放着不管如果不自动退出路过的读者就可能操作后台。加了超时之后这个风险就基本消除了。3.3 图书CRUD与检索PDO预处理到底防住了什么图书管理的主流程是新增书目→贴条码→上架→读者借阅→归还核心操作都是围绕图书记录表展开的。我在写图书新增功能时一开始直接用字符串拼接SQL$sql INSERT INTO books (title, isbn, author, category, location) VALUES ($title, $isbn, $author, $category, $location);这要是有人在前端表单里输入一条 ; DROP TABLE books; --那就是灾难。我后来全部改成PDO预处理用占位符传参$stmt $pdo-prepare(INSERT INTO books (title, isbn, author, category, location) VALUES (?, ?, ?, ?, ?)); $stmt-execute([$title, $isbn, $author, $category, $location]);预处理的好处是参数和SQL语句分开发送到数据库参数只作为数据被处理不会变成SQL指令的一部分。这个不是PHP特有的技巧是数据库层面的功能但PDO让使用变得很简单。图书检索我用了最简单但好用的方式关键词LIKE匹配加分类筛选。用SQL拼一个动态条件注意每一段都用预处理参数$conditions []; $params []; if (!empty($keyword)) { $conditions[] (title LIKE ? OR author LIKE ? OR isbn LIKE ?); array_push($params, %$keyword%, %$keyword%, %$keyword%); } if (!empty($category)) { $conditions[] category ?; $params[] $category; } $where_sql $conditions ? (WHERE . implode( AND , $conditions)) : ; $stmt $pdo-prepare(SELECT * FROM books $where_sql ORDER BY created_at DESC); $stmt-execute($params);这种方式唯一的性能瓶颈是LIKE %keyword% 会导致全表扫描但馆藏也就几万册加上索引后查询基本都在几十毫秒以内。如果未来书库量涨到几十万本那就得上全文索引或考虑MySQL的全文搜索了当前阶段用不着。4. 上线前踩过的坑PHP常见错误、中文乱码和序列化问题4.1 白屏之痛从页面啥都不显示到看错误日志开发过程中我遇到最多的就是白屏。页面访问后一片空白什么错误信息都没有。第一反应是代码写错了但不知道错在哪。后来才发现PHP的display_errors默认在生产环境是关闭的所有错误都被写进日志里而你什么都看不到。解决办法分两步。开发阶段在入口文件顶部开启错误显示ini_set(display_errors, 1); ini_set(display_startup_errors, 1); error_reporting(E_ALL);上线后肯定不能把错误直接显示给用户但也不能完全隐藏正确做法是配置日志记录。我用的是phpStudy配置Apache环境变量log_errors On error_log D:/wwwlogs/php_error.log然后在公共文件里做一个自定义异常处理器和错误处理器把错误详情写进日志用户端只看到友好的系统繁忙请稍后再试。我印象最深的一个错误是我在一个函数里用了另一个文件里定义的函数但忘记包含那个文件白屏了两三个小时才通过日志定位到是undefined function的报错。从那以后我养成了一个习惯所有自定义函数文件都在入口文件里集中include_once而不是在每个业务脚本里零散包含。4.2 PHP序列化中文的坑我自己遇到的一个很实际的坑把数组存到数据库或缓存时用了序列化结果中文变成了乱码。这个现象的根本原因是seralize出来的字符串包含不可见字符和长度前缀如果存进varchar字段时没有正确设置编码或者数据库字段是latin1字符集中文就会被截断或转义成乱码。后来我改用两个方案一是序列化后base64_encode再存$data [name 中文, list [1,2,3]]; $stored base64_encode(serialize($data)); // 读取时 $restored unserialize(base64_decode($stored));二是干脆用JSON代替序列化$stored json_encode($data, JSON_UNESCAPED_UNICODE); $restored json_decode($stored, true);JSON的方式在我这个项目里更合适因为JSON字符串是文本格式可读性好字段一多不会出现奇奇怪怪的字符。如果你存的是PHP对象而且需要保留对象类型才考虑serialize加base64的方式。4.3 跨域和接口调试前台读者端和后台管理端的分离系统里读者端是一个独立的页面放在图书馆大厅的公共查询机上通过AJAX调后台接口查询馆藏图书和个人借阅记录。这里就遇到了跨域问题。公共查询机的浏览器访问的是http://192.168.1.88:8080/opac/后台管理端是http://192.168.1.88/admin/端口和路径不一样浏览器默认会拦截跨域请求。我处理的方式是在公共接口文件夹里加一个统一的响应头header(Access-Control-Allow-Origin: *); header(Access-Control-Allow-Methods: GET, POST, OPTIONS); header(Access-Control-Allow-Headers: Content-Type);如果未来要限制来源可以把改成具体的域名。注意如果请求涉及带Cookie的会话认证Access-Control-Allow-Origin不能是而必须是明确的来源还要加Access-Control-Allow-Credentials: true。我这边读者查询接口是不需要会话的所以用了宽松配置。调试的时候用Chrome的F12开发者工具看Network面板能很清楚地看到AJAX请求有没有被CORS拦截以及返回状态码和响应体。新手写接口如果遇到跨域无效优先检查响应头有没有正常输出以及是不是有PHP警告信息混在JSON响应前面导致JSON解析失败。4.4 文件包含漏洞一个容易忽略的安全隐患求助帖里经常有人遇到include $_GET[page]这样的写法然后就被利用来读取任意文件。我在写页面路由时避免了这个设计而是用白名单方式$page $_GET[page] ?? dashboard; $allowed_pages [dashboard, books, borrows, readers, roles, logs]; if (!in_array($page, $allowed_pages)) { $page dashboard; } include ./views/{$page}.php;用户能传进来的page值被限制在一个固定列表里不会变成路径穿越的入口。这个习惯后来救了我一次有同事在测试时随手在URL里输入了../config.php结果被白名单拦截返回了默认页要是没做白名单数据库账号密码可能就裸奔了。5. 从本机跑通到局域网部署让系统真正被同事们用起来5.1 环境搭建的最终配置我开发时用的是Windows上的phpStudyApachePHP 7.4MySQL 5.7组合上线部署延续了同一套环境主要原因是迁移成本最低。下面配置里有点容易忘记的部分PHP启用扩展pdo_mysql、mysqli、openssl、mbstring、curl这些在php.ini里要把前面的分号去掉Apache开启mod_rewrite模块因为我用了伪静态美化URL同时配置AllowOverride AllMySQL的字符集统一设置为utf8mb4而不是utf8因为utf8mb4才能存储四字节的emoji和一些特殊字符关闭目录列表在httpd.conf里把Options Indexes的Indexes去掉防止用户直接浏览文件目录数据库连接方面我在配置文件里维护了一个PDO单例function get_db_connection() { static $pdo null; if ($pdo null) { $dsn mysql:host127.0.0.1;dbnamelibsys;charsetutf8mb4; $options [ PDO::ATTR_ERRMODE PDO::ERRMODE_EXCEPTION, PDO::ATTR_DEFAULT_FETCH_MODE PDO::FETCH_ASSOC, PDO::ATTR_EMULATE_PREPARES false, ]; $pdo new PDO($dsn, libuser, password, $options); } return $pdo; }PDO::ATTR_EMULATE_PREPARES设为false是告诉PDO不要模拟预处理真的把预处理交给MySQL执行这样SQL注人的防护更彻底同时还能避免某些版本下LIMIT参数用预处理出错的问题。5.2 局域网访问的几个坎开发时我用127.0.0.1访问一切正常但一旦让借阅台的同事访问就遇到一堆问题。第一是防火墙拦了80端口。Windows Server自带的防火墙默认不放行外部访问80端口的流量我需要在防火墙高级设置里添加入站规则允许TCP 80端口。第二是Apache默认监听localhost如果httpd.conf里的Listen是127.0.0.1:80外部访问自然不通。改成Listen 0.0.0.0:80即可。第三是MySQL的权限。默认root账户可能只允许localhost登录PHP跑在和MySQL同一个服务器上倒是无所谓但千万别把数据库账号密码写死在页面HTML里。我用的是独立账号libuser权限只授予libsys这个库最小权限原则在数据库层面也适用。5.3 备份策略一点不夸张备份救了我的命系统跑了大概两个月后有次我执行批量更新时SQL的WHERE条件写错了一下把一百多本图书的馆藏位置全改错了。当时心里拔凉拔凉的还好我每天凌晨用计划任务自动备份数据库mysqldump -ulibuser -ppassword libsys D:\backup\libsys_%date:~0,4%%date:~5,2%%date:~8,2%.sql这行批处理在Windows计划任务里每天3点执行一次保留最近七天。数据恢复时只丢了一天的更新操作重新录入了一批当天新上架的书就行。管理员系统里我还加了一个操作日志表记录谁在什么时间改了什么数据这个在回溯问题时非常有用建议每一位自己写管理系统的朋友都加上这个表。6. 写下这套系统后我送给同样非科班的几点经验如果你也打算自己动手写一个小型管理系统我的建议是别急着找现成的框架把原生PHP这几个点吃透——PDO预处理、Session管理、RBAC权限模型、文件包含和目录安全。这些是任何管理系统都躲不掉的底层能力。还有一个心得是角色的设计一定要一开始就想清楚谁能干什么再动手。我先写代码后做权限模型导致中间重构了一次用户表和相关逻辑浪费了至少一个周末的时间。正确的顺序是先画角色和权限清单再去写登录和菜单渲染。至于外界常说的PHP已经过时之类的声音我在这个项目里没感觉到什么影响。图书馆管理系统不需要高并发不需要微服务PHP配合MySQL在局域网内跑得又快又稳定而且我这种半路出家的人维护起来几乎没有门槛。工具是否合适始终要结合自己的场景来判断的。这台旧服务器到现在还很稳系统也一直在馆里运行着。如果你也在琢磨一个类似的小项目不知道从哪里开始我的建议是找一个最痛的业务场景切入比如图书管理里的借还流程先打通一条最简单的链路再逐步加上多角色和权限控制你会发现当需求足够具体的时候技术其实没那么难。