简介面向PHP初中级开发者这套基于ThinkPHP5与Layui深度整合的后台系统项目包提供了完整的开发基础能够快速搭建起包含用户管理、角色权限、系统设置、日志记录等模块的企业级管理后台。压缩包约11MB以PHP源码和SQL数据库脚本为主要内容其中SQL脚本包含用户表、角色表、权限表及关联表的结构定义和初始化数据解压后即可导入数据库使用。项目展示了ThinkPHP5的路由、中间件、服务容器等核心机制以及Layui的表格、表单、弹窗等组件在真实业务中的调用方式同时说明了数据增删改查、权限控制等功能的实现思路对理解前后端数据交互与业务流程非常有帮助。目前已有679人学习下载无论用于学习MVC架构还是作为二次开发的起点这套资源都具备较高的实战参考价值。1. 这套 ThinkPHP5 后台系统为什么到现在还有参考价值后台管理系统是 Web 开发里最不容易出彩、却最绕不开的一类项目。前几年用 ThinkPHP5 搭后台几乎是中小型团队的默认选项今天再看这套含数据库脚本的 rar 包它的价值不在「能不能直接上线」而在于它把一个后台系统最典型的骨架完整地摆在了你面前用户、角色、权限、日志、系统设置配合 Layui 的表格与弹窗交互。你把它拆开看一遍相当于把 PHP 后台开发的常规套路重新走了一遍——从 SQL 建表到 TP5 的模型查询再到 Layui 的异步渲染这条链路在 TP6、TP8 里依旧成立。另一个现实问题是网上大量存量项目跑在 ThinkPHP5 上你早晚要接手这类代码。与其到时候从零看起不如现在把框架版本差异、权限表设计、前端渲染方式一起理清。这套系统的数据库脚本和模块划分恰恰覆盖了这些关键点对初学 PHP 的人是一份能跑起来的完整样本对要维护老项目的人则是现成的参照物。2. ThinkPHP5 的目录结构与后台模块的对应关系2.1 单入口与模块划分的基本逻辑ThinkPHP5 采用单入口模式所有请求都经过public/index.php进入框架。拿到 rar 包解压后第一件事不是看代码而是对照目录确认版本和结构。TP5 的标准目录分成application、public、thinkphp和extend四块这套后台系统的业务代码集中在application下。project-root/ ├── application/ │ ├── admin/ # 后台管理模块 │ │ ├── controller/ # 控制器 │ │ ├── model/ # 模型 │ │ └── view/ # 视图模板 │ ├── index/ # 前台模块如果有 │ └── command.php # 命令行配置 ├── public/ │ ├── index.php │ └── static/ # 静态资源layui 等 ├── thinkphp/ └── .env # 环境配置数据库连接等后台系统的模块划分通常会单独建一个admin目录而不是跟前台混在一起。这样做的收益很直接只需要在入口文件或者路由规则里加上后台模块的前缀判断就能把管理端和用户端隔离开。注意application下的目录是自动加载的映射基础新增模块时不要随意改大小写。2.2 配置文件的加载顺序与数据库连接TP5 的配置读取顺序是惯例配置 → 应用配置 → 扩展配置 → 场景配置。后台系统的数据库连接信息写在application/database.php或.env文件里推荐用.env管理避免把数据库账号密码提交到版本库。?php // .env 文件内容示例 APP_DEBUG true [DATABASE] TYPE mysql HOSTNAME 127.0.0.1 DATABASE admin_system USERNAME root PASSWORD your_password HOSTPORT 3306 CHARSET utf8mb4 PREFIX tp_配置完成后在控制器里通过Db::name(user)就能直接操作tp_user表不需要写类名。这里要注意PREFIX的作用它让代码里写表名时不用带前缀换库迁移时只改一处配置避免在 SQL 和模型中到处替换。2.3 控制器的继承与公共逻辑抽取后台系统的每个控制器几乎都有登录校验、权限判断、日志记录这些公共逻辑。TP5 的控制器继承机制允许把所有后台模块的公共方法抽到一个BaseController里子控制器继承它即可。?php namespace app\admin\controller; use think\Controller; use think\facade\Session; class BaseController extends Controller { protected function initialize() { parent::initialize(); // 校验后台登录状态 if (!Session::has(admin_id)) { $this-error(请先登录, admin/login/index); } } protected function successResponse($data []) { return json([code 1, data $data, msg 操作成功]); } protected function errorResponse($msg 操作失败) { return json([code 0, msg $msg]); } }initialize方法是 TP5 控制器初始化的入口在继承体系中会先于控制器的具体方法执行。这段代码的作用是所有继承BaseController的后台控制器在进入业务逻辑前都会自动检查 Session 里的admin_id不存在就跳转登录页。这样每个控制器只需要关注自己的业务方法登录校验不用重复粘贴。successResponse和errorResponse是给前端 Layui 统一返回 JSON 格式用的后面表格渲染时会直接消费这个结构。3. 数据库脚本表结构设计与权限模型落地3.1 从 SQL 脚本反推业务设计数据库脚本是整个压缩包里最值得先读的文件。它不只是建几张表而是定义了这套后台系统的权限模型。大多数 TP5 后台系统的表结构是围绕 RBAC基于角色的访问控制设计的这套系统的 SQL 脚本里通常包含用户表、角色表、权限表或节点表、用户-角色关联表、角色-权限关联表以及系统配置表和日志表。-- 管理员用户表 CREATE TABLE tp_admin_user ( id int(11) unsigned NOT NULL AUTO_INCREMENT, username varchar(50) NOT NULL COMMENT 登录名, password varchar(255) NOT NULL COMMENT 密码hash, real_name varchar(50) DEFAULT COMMENT 真实姓名, role_id int(11) DEFAULT 0 COMMENT 角色ID, status tinyint(1) DEFAULT 1 COMMENT 1启用 0禁用, last_login_time int(11) DEFAULT 0 COMMENT 最后登录时间, last_login_ip varchar(50) DEFAULT COMMENT 最后登录IP, create_time int(11) DEFAULT 0, update_time int(11) DEFAULT 0, PRIMARY KEY (id) ) ENGINEInnoDB AUTO_INCREMENT1 DEFAULT CHARSETutf8mb4 COMMENT管理员表; -- 角色表 CREATE TABLE tp_role ( id int(11) unsigned NOT NULL AUTO_INCREMENT, name varchar(50) NOT NULL COMMENT 角色名称, remark varchar(255) DEFAULT COMMENT 备注, status tinyint(1) DEFAULT 1, create_time int(11) DEFAULT 0, PRIMARY KEY (id) ) ENGINEInnoDB AUTO_INCREMENT1 DEFAULT CHARSETutf8mb4 COMMENT角色表; -- 权限节点表 CREATE TABLE tp_menu ( id int(11) unsigned NOT NULL AUTO_INCREMENT, pid int(11) DEFAULT 0 COMMENT 父级ID, name varchar(50) NOT NULL COMMENT 菜单名, url varchar(255) DEFAULT COMMENT 路由地址, icon varchar(50) DEFAULT COMMENT 图标, sort int(11) DEFAULT 0, status tinyint(1) DEFAULT 1, PRIMARY KEY (id) ) ENGINEInnoDB AUTO_INCREMENT1 DEFAULT CHARSETutf8mb4 COMMENT菜单/权限表; -- 角色-权限关联表 CREATE TABLE tp_role_menu ( role_id int(11) NOT NULL, menu_id int(11) NOT NULL, PRIMARY KEY (role_id, menu_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT角色菜单关联表;TP5 自带的底层方法对密码处理支持得不够直观多数后台系统会在模型层重写密码逻辑。常见做法是在AdminUser模型里定义一个 setter写入时自动用password_hash生成验证时用password_verify检查避免在控制器里到处写加密代码。?php namespace app\admin\model; use think\Model; class AdminUser extends Model { protected $name admin_user; public function setPasswordAttr($value) { return password_hash($value, PASSWORD_DEFAULT); } public function verifyPassword($password) { return password_verify($password, $this-password); } }setPasswordAttr是 TP5 模型的数据自动处理机制当代码给模型的password字段赋值时会自动执行这个 setter。这样AdminUser::create([usernameadmin,password123456])写入的就已经是 hash 值。而verifyPassword把验证逻辑收敛在模型里登录控制器只需要调用一个方法即使以后更换加密算法也只改这一个地方。3.2 权限控制如何在 TP5 里落地数据表设计好了下一步是让权限判断真正拦截每个请求。TP5 的中间件机制虽然可用但在这类传统后台系统里更常见的是在BaseController的构造逻辑里做节点校验或者使用自定义路由检测。如果你的tp_menu表里存的路由是admin/user/index这种格式那么每次请求进来时取出当前用户的角色所关联的菜单列表判断当前路由是否在列表内。?php protected function checkAuth() { $adminId Session::get(admin_id); if ($adminId 1) { return true; // 超级管理员跳过校验 } $roleId Db::name(admin_user)-where(id, $adminId)-value(role_id); $url strtolower(request()-module() . / . request()-controller() . / . request()-action()); $allowUrls Db::name(role_menu) -alias(rm) -join(menu m, rm.menu_id m.id) -where(rm.role_id, $roleId) -column(m.url); if (in_array($url, $allowUrls)) { return true; } $this-error(没有访问权限); }这个实现方式有一个坑要注意column(m.url)返回的一维数组默认以url字段名为 key如果你的两个菜单url相同只会保留一条。处理办法是用Db::name(role_menu)-alias(rm)-join(menu m,rm.menu_id m.id)-where(rm.role_id,$roleId)-column(m.url, m.id)把主键作为 key这样能避免数组覆盖。控制器的层数深了之后request()-controller()返回的可能是驼峰格式要和tp_menu表里存的路径统一成小写再比较。3.3 导入数据库脚本的两种方式拿到 rar 包里的.sql文件导入方式取决于现有环境。本地用 phpMyAdmin 或者 Navicat 这类图形工具直接执行文件即可但服务器上通常只有命令行这时候要会用 mysql 命令。# 先创建数据库并指定字符集 CREATE DATABASE IF NOT EXISTS admin_system DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; # 导入 SQL 文件 mysql -u root -p admin_system /path/to/admin_system.sql # 查看导入是否成功 mysql -u root -p -e USE admin_system; SHOW TABLES;导入完成后检查三件事表数量是否和 SQL 文件里的建表语句数量一致tp_admin_user里有没有初始管理员账号tp_menu表是否完整。很多情况下 SQL 脚本里的初始密码是明文123456首次登录后台后要立刻改掉。TP5 的Db::name(admin_user)-where(id,1)-update([password password_hash(new_pass, PASSWORD_DEFAULT)])可以快速重置。4. Layui 后台界面与 ThinkPHP5 的异步交互4.1 表格组件的动态渲染Layui 在这个后台系统里主要承担数据展示和操作交互。它的表格组件table依赖后端返回特定格式的 JSON 数据这一点和 TP5 的分页封装天然吻合。后端控制器输出分页时常见做法是统一返回code、count、data三个字段。code固定用 0 表示成功count是总记录数data是当前页列表Layui 的表格模块只认这套格式。?php namespace app\admin\controller; use think\Controller; use think\Db; class User extends Controller { public function index() { return $this-fetch(); } public function userList() { $page input(param.page, 1); $limit input(param.limit, 10); $where []; if (input(param.keyword)) { $where[username] [like, % . input(param.keyword) . %]; } $count Db::name(admin_user)-where($where)-count(); $list Db::name(admin_user) -where($where) -page($page, $limit) -select() -toArray(); return json([code 0, count $count, data $list]); } }Layui 表格默认通过 HTTP 的 GET 请求向接口地址发送page和limit两个参数page代表当前页码limit代表每页条数。后端用input(param.page, 1)接收时给了默认值防止首次加载时参数缺失。这个接口的关键点在于count必须查全表符合条件的总数而不是当前页的数量否则 Layui 的分页组件会少一页或多一页。前端视图里对应的是table.render的调用layui.use([table, layer], function () { var table layui.table; table.render({ elem: #userTable, url: /admin/user/userList, page: true, cols: [[ { field: id, title: ID, width: 80 }, { field: username, title: 登录名, width: 120 }, { field: real_name, title: 姓名, width: 120 }, { field: status, title: 状态, width: 100, templet: #statusTpl }, { title: 操作, toolbar: #userToolbar, width: 200 } ]], response: { statusCode: 0 } }); });这里的response.statusCode要和后端返回的code值保持一致。如果后端用了successResponse返回code: 1那这里就要改成statusCode: 1否则表格一直显示「接口异常」。很多新手在联调时最容易栽在这个地方后端认为约定好了前端也认为约定好了但两个值对不上数据就是不出来。4.2 表单提交与弹窗编辑的联动后台系统的另一个高频场景是新增和编辑。Layui 的layer.open配合 iframe 页面实现表单弹窗表单提交则通过form.on(submit)拦截走 Ajax 请求到 TP5 控制器。// 新增按钮事件 $(#addBtn).on(click, function () { layer.open({ type: 2, title: 新增用户, content: /admin/user/add, area: [500px, 420px], end: function () { table.reload(userTable); } }); }); // 表单提交在新增页面里 layui.use([form], function () { var form layui.form; form.on(submit(saveBtn), function (data) { $.post(/admin/user/save, data.field, function (res) { if (res.code 0) { var index parent.layer.getFrameIndex(window.name); parent.layer.close(index); } else { layer.msg(res.msg); } }, json); return false; }); });layer.open的type: 2表示嵌入 iframe 页面end回调会在弹窗关闭后触发这里用来让父页面的表格重新加载数据。注意form.on(submit(saveBtn))里saveBtn必须和表单提交按钮的lay-filter属性一致否则事件绑不上。提交时用data.field拿到整个表单的键值对直接作为 POST 参数传给 TP5 的save方法。TP5 端接收数据后常规写法是区分新增和更新public function save() { $data input(post.); if (empty($data[id])) { $data[password] 123456; // 默认密码 Db::name(admin_user)-insert($data); } else { unset($data[password]); // 编辑时禁止更新密码 Db::name(admin_user)-update($data); } return json([code 0, msg 保存成功]); }这段代码里有一个需要留意的安全细节直接insert($data)会把表单里所有字段都写入数据库如果表里有status、role_id这类字段攻击者可以通过构造表单数据将其篡改。更稳妥的方式是在写入前unset掉不允许前端直接赋值的字段或者用模型器配合allowField过滤。这也是 TP5 老项目常见的安全短板接手任何后台系统时都应该排查一遍。4.3 日期控件与下拉框的常见处理Layui 的后台模板里日期范围选择和数据筛选是高频组件。搜热词里提到「layui date 最大日期当前日期」确实用日期组件时有三个容易出错的地方一是laydate.render必须在layui.use回调里执行二是传给value的初始值必须是YYYY-MM-DD格式字符串三是动态修改日期值后要调用laydate实例的reload方法重置直接改输入框的 value 不会触发组件内部状态更新。layui.use([laydate, form], function () { var laydate layui.laydate; var form layui.form; laydate.render({ elem: #startTime, max: getToday(), // 限制最大日期为今天 done: function (value) { form.render(select); } }); function getToday() { var d new Date(); return d.getFullYear() - (d.getMonth() 1) - d.getDate(); } });另一个高频问题「layui select 动态赋值」常见场景是角色下拉框在页面加载后通过 Ajax 获取数据。直接给select加 option 是不够的必须调用form.render(select)刷新组件否则页面上的下拉框还是空的。这里的逻辑是Layui 把原生 select 隐藏掉了用自己渲染的 div 展示原生 DOM 变化后不通知 Layui需要手动调用渲染方法让它重新读一次 DOM。$.get(/admin/role/getAll, function (res) { var html option value请选择角色/option; res.data.forEach(function (item) { html option value item.id item.name /option; }); $(#roleSelect).html(html); form.render(select); });这里要注意form.render(select)的作用范围。默认是渲染整个表单如果页面里有多个 select只想更新其中一个可以给容器加lay-filter属性然后调用form.render(select, filterName)。这个细节在处理表格行内下拉框时尤其重要不然每行数据刷新都会导致全部下拉框重置到初始状态。4.4 静态资源路径与入口文件的坑Layui 的静态资源放在public/static目录下访问路径是/static/layui/layui.js。TP5 的入口文件虽然是public/index.php但视图模板里引用静态资源时不能写相对路径否则在多层路由下会找不到文件。正确做法是在模板里用 TP5 提供的__STATIC__常量或者直接写/static/绝对路径。link relstylesheet href/static/layui/css/layui.css script src/static/layui/layui.js/script如果你的项目部署在子目录比如http://localhost/admin_system而不是域名根目录这里的/static/就会失效。解决办法有两个一是用{:request()-root()}拼接根路径二是用 TP5 的路由配置把静态目录映射到根路径。这个坑在从本地迁移到服务器时特别容易暴露表现为后台页面样式全丢、弹窗功能失灵但接口请求和页面跳转都正常。5. 模块扩展与分层用户管理之外的通用模板5.1 仿照现有控制器快速新增业务模块既然理解了一套模块的完整链路数据库表 → 模型 → 控制器 → 视图 → JS后面新增模块其实就是复制粘贴再改名字。适合用这套后台系统的场景包括文章管理、分类管理、商品管理、订单管理等它们的共同特点是针对单张或多张关联表做 CRUD。以新增一个「公告管理」模块为例复用这套结构的成本很低。先建一张tp_notice表字段包含id、title、content、create_time然后在application/admin/controller下新建Notice.php最后在application/admin/view下新建notice目录把user模块的index.html复制过去改一下表格列。整套流程在半小时内完成前提是理解了 4.1 节里 Layui 表格的数据格式约定。5.2 搜索条件的通用写法与安全过滤表格列表页几乎都要带搜索条件。这类后台系统的搜索表单通常由时间范围、关键字、状态下拉框组成。后端接收参数时不要直接拼 SQL用查询构造器的数组条件更安全。$where []; if ($keyword input(param.keyword)) { $where[title] [like, % . $keyword . %]; } if ($status input(param.status, )) { $where[status] $status; } $startTime input(param.start_time, ); $endTime input(param.end_time, ); if ($startTime $endTime) { $where[create_time] [ [, strtotime($startTime . 00:00:00)], [, strtotime($endTime . 23:59:59)] ]; }input(param.status, )的第二个参数是默认值。当 URL 里没有status参数时返回空字符串这样if ($status)判断失败不会进入条件。如果不用默认值而是直接用input(param.status)未传参时返回 null$where[status] null会导致查询条件变成status IS NULL查出来的数据完全不对。时间字段如果数据库存的是 int 型时间戳前端传过来的是字符串必须用strtotime转换后再比较。这里的[, ...], [, ...]二维数组写法是 TP5 查询构造器的特殊支持它能生成create_time ... AND create_time ...的 SQL。5.3 日志模块与操作审计的实现思路日志管理是后台系统里容易被忽略但实际非常重要的模块。这套系统的 SQL 脚本里如果有tp_log表通常包含admin_id、action、url、ip、content、create_time等字段。实现方式有两种一种是在BaseController里统一记录另一种是手动在关键操作处调用日志方法。前者覆盖全面后者更灵活但容易漏记。protected function writeLog($content) { Db::name(log)-insert([ admin_id Session::get(admin_id), username Session::get(admin_name), url request()-url(), ip request()-ip(), content $content, create_time time() ]); }如果要在BaseController里统一记录所有后台操作可以改写initialize方法在权限校验之后追加日志逻辑。但要注意登录请求的 action 不应该记录否则会把自己的登录动作写进日志。可以在writeLog里加一个白名单判断对login/index这类路由跳过记录。另外状态码为 404 的请求通常直接由框架处理不会经过控制器所以这类异常不会出现在操作日志里需要另外用框架的异常处理记录不能只依赖这个方案。6. 从 ThinkPHP5 迁移到 ThinkPHP8 的差异要点ThinkPHP5 和 ThinkPHP8 都是国内外开发者绕不开的话题但如果你只是把老后台系统从 5 升到 8会发现很多写法直接报错或者表现不同。下面是几个最典型的差异点。6.1 助手函数与类库的变动ThinkPHP5 里的Db::name()、input()、session()这些写法在 ThinkPHP8 里依旧保留但底层实现变化不小。TP8 不再使用think\facade\Session的静态代理方式而是推荐通过依赖注入或者think\facade\Db门面来操作。如果你只改了 composer 版本代码里的use think\facade\Session;在 TP8 里需要换成use think\facade\Session;仍然存在但session()助手函数的行为更严格了比如设置过期时间、跨应用处理的方式都与 TP5 不同。// TP5 写法 $list Db::name(user)-where(status, 1)-select(); // TP8 推荐写法 use think\facade\Db; $list Db::name(user)-where(status, 1)-select();表面看代码几乎一样但 TP8 里select()返回的是 Collection 对象而不是数组直接json_encode输出是没问题的但如果用foreach ($list as $item)然后$item[name]取值必须先用$list-toArray()转成数组或者用$item-name的方式读取。6.2 多应用模式与路由定义的变更TP5 默认是单应用模式进入后台需要拼接/admin/user/index这样的完整路径。TP8 默认支持多应用模式每个应用是一个独立的目录后台要拆成app/admin下的独立应用时才不会访问冲突。把 TP5 后台迁移到 TP8 时如果还是放在application/admin目录需要在config/app.php里配置auto_multi_app才能继续以路径方式访问。另一个大的坑是validate机制。TP5 的验证器定义在application/validate下TP8 里统一放到app/validate且命名空间从app\validate改为think\validate的独立性更强。后台系统的表单验证如果用了验证器迁移时要检查use语句里的类路径。// TP5 验证器调用 $validate Validate::make([name require|max:25]); if (!$validate-check($data)) { $this-error($validate-getError()); }这两个框架版本在底层差异很大但如果你只是维护存量项目未必要急着迁移。实际做法是先把系统跑在 PHP 7.4 上维持 TP5 稳定工作新项目再用 TP8 开发不要把老代码硬迁——ThinkPHP5 的一些设计缺陷比如add方法、字符串条件查询在 TP8 里已经被彻底移除硬迁等于重写。6.3 迁移后必查的兼容性问题清单检查项TP5 写法TP8 影响Db::query()返回结果数组结果集对象需toArray()Route::get()定义闭包或控制器闭包路由默认缓存异常模板引擎 {$listimplode,}可用U()函数已弃用使用url()助手函数替代模块清晰度靠目录多应用模式下更清晰迁移老系统时建议先用 PHPStan 或 grep 搜索代码里的U(、I(、M(这类 TP3 遗留函数它们混在 TP5 代码里本身就是隐患在 TP8 里直接就是 fatal error。另外 TP8 对 PHP 版本要求是 8.0 以上如果服务器还跑着 PHP 7.2更新前一定要确认环境兼容性。这套系统作为学习样板可以反复对照分析真正放到生产环境前记得把数据库脚本里的测试数据清理掉重新生成一套自己的初始账号和菜单权限配置。本文还有配套的精品资源点击获取