PHP轻量工单系统源码包：含前后端代码、MySQL配置与Nginx/Apache部署脚本

本文还有配套的精品资源，点击获取

简介：适合有PHP基础的开发者快速搭建内部工单管理平台，支持用户提交工单、管理员分配处理、实时状态更新和进度追踪，界面响应式设计，PC和手机都能顺畅操作。后端基于PHP 7.2+，无需复杂框架，直接运行在Linux服务器上，兼容Nginx和Apache两种Web环境；数据库使用MySQL 5.5+，提供完整配置模板（.env.install）和多套路由规则（.htaccess、nginx.htaccess）。前端资源齐全，包含app.css、login.css、app.js、util.js等核心样式与脚本，还有验证码校验（verify.js）、微信小程序二维码生成（weapp-qrcode.js）、图标（favicon.ico）和默认头像（avatar.jpeg）。配套安装说明.md清晰列出部署步骤，无第三方前端框架依赖，目录结构扁平易读，方便按需删减或扩展功能模块。

1. 这不是又一个“Demo级”工单系统，而是一套能直接塞进你公司内网跑起来的生产就绪型PHP工单底座

我见过太多标榜“轻量”的PHP工单源码——点开压缩包，里面是Laravel全家桶、Vue CLI脚手架、Webpack配置嵌套三层、node_modules占200MB，部署前先得配好Composer、Node.js、npm、MySQL服务、Redis缓存、队列监听器……最后发现，光环境准备就得花半天，更别说改个登录页颜色还得翻三遍文档。这套东西完全反其道而行之：它不追求“技术炫技”，只解决一个最朴素的问题——让行政、IT支持、客服组长这类非专职开发人员，在一台刚重装完CentOS 7的虚拟机上，30分钟内把一个能收工单、能分派、能查进度的后台真正用起来。

核心关键词我已经在开头埋好了：PHP工单系统、轻量工单源码、MySQL工单后台、Nginx部署脚本。这四个词不是标签，而是它的DNA。它不依赖任何PHP框架（Laravel、ThinkPHP、CodeIgniter？统统没有），所有路由逻辑写在app.php里，数据库操作封装在database.php中，连PDO连接池都懒得搞——因为真实场景下，一个50人规模的内部支持团队，日均工单量撑死200条，用原生PDO+简单查询缓存，比硬套一个ORM框架快且稳得多。前端更是“裸奔式”设计：没有Vue/React编译流程，app.js就是纯ES5语法写的DOM操作+AJAX封装，app.css用的是BEM命名法手写的响应式栅格，连Flexbox都没用（兼容IE11是硬性要求，很多老厂OA系统还在用IE内核）。你打开index.html，能看到清晰的<script src="app.js"></script>和<link rel="stylesheet" href="app.css">，而不是一堆<script type="module">和import { createApp } from 'vue'。这不是技术倒退，而是对真实部署场景的精准拿捏——当你在客户现场调试一台连外网都没有的Windows Server服务器时，你不会感谢那个要求你先npm install --global yarn的“现代化”系统。

它适合谁？明确说：有PHP基础，能看懂$_POST['title']和$pdo->prepare()的人；能SSH登录Linux服务器，会敲systemctl restart nginx的人；需要快速上线一个“能用就行、别太花哨、最好别让我天天维护”的内部协作工具的人。如果你是刚学完PHP语法的学生，它可能有点门槛（毕竟没给你封装好一切）；如果你是资深架构师，它可能显得“简陋”（确实没微服务、没K8s部署清单）。但它卡在一个极其精准的中间地带：给一线运维、IT主管、小团队技术负责人，提供一套零学习成本、零环境依赖、零后期维护焦虑的工单底盘。我去年帮一家医疗器械代理商部署这套系统，他们连专职IT都没有，只有个懂点Excel的行政专员。我把安装说明.md打印出来，她照着步骤，从下载源码、上传到VPS、执行bash deploy-nginx.sh、填好数据库密码，到最后在手机微信里点开链接提交第一条“打印机卡纸”工单，总共用了22分钟。这才是“轻量”的真实含义：不是代码行数少，而是决策链路短、失败节点少、知识门槛低。

2. 整体设计思路拆解：为什么放弃框架、坚持原生、拥抱“过时”技术栈？

2.1 放弃框架不是偷懒，而是为稳定性与可预测性主动降维

很多人看到“无框架”第一反应是“不安全”“难维护”。但我要反问：一个日均处理200条工单的系统，它的最大风险是什么？是SQL注入？XSS攻击？还是——某天凌晨三点，线上工单突然无法提交，排查发现是Laravel升级后某个中间件的handle()方法签名变了，而你的运维同事正在休假？这套系统的全部后端逻辑加起来不到1200行PHP代码（app.php+database.php+auth.php三文件合计），所有数据库查询都是预处理语句（$stmt = $pdo->prepare("SELECT * FROM tickets WHERE id = ?"); $stmt->execute([$id]);），所有用户输入都经过filter_var()过滤（邮箱用FILTER_VALIDATE_EMAIL，数字用FILTER_SANITIZE_NUMBER_INT），所有输出到HTML的变量都用htmlspecialchars()转义。它没有“中间件生命周期”“服务容器绑定”“事件广播机制”这些抽象层，意味着每一行代码的执行路径都是100%可追踪、可预测的。当submit_ticket.php报错时，错误日志里直接指向第47行$pdo->exec($sql)，而不是层层调用栈里第17层某个匿名函数的闭包作用域。

再看部署复杂度对比。一个典型Laravel工单系统部署流程是：
1. 安装PHP 8.1+、Composer、Node.js 16+
2.composer install --no-dev --optimize-autoloader（耗时3-5分钟）
3.npm ci && npm run build（耗时8-12分钟，且需package-lock.json匹配）
4. 配置.env、生成APP_KEY、运行php artisan migrate
5. 设置storage:link、cache:clear、config:clear
6. 配置Web服务器重写规则（Apache需mod_rewrite，Nginx需try_files）
7. 启动队列监听器（php artisan queue:work）

而本系统的部署流程是：
1. 上传源码包到/var/www/ticket
2.chmod -R 755 /var/www/ticket
3.cp .env.install .env && vim .env（填入DB_HOST/DB_NAME/DB_USER/DB_PASS）
4.bash deploy-nginx.sh（或deploy-apache.sh）
5.chown -R www-data:www-data /var/www/ticket
6.systemctl restart nginx

时间差不是几分钟，而是心智负担的质变。前者要求你理解Composer autoload机制、Webpack模块解析、Laravel Service Provider注册顺序；后者只要求你知道cp和vim怎么用。这就是设计哲学的根本差异：框架追求“开发者体验”，而本系统追求“运维者体验”。

2.2 前端“复古”设计：不碰现代构建工具，只为一次部署永久生效

前端目录里没有src/、dist/、build/，只有css/、js/、images/三个扁平文件夹。app.css是手写的，总大小仅87KB，但实现了完整的响应式断点：
-@media (max-width: 768px)：隐藏侧边栏导航，工单列表改为单列卡片流
-@media (min-width: 769px) and (max-width: 1024px)：显示精简版顶部导航，工单详情页左右分栏
-@media (min-width: 1025px)：完整双栏布局，左侧菜单+右侧内容区

关键在于，它用纯CSS实现，不依赖JavaScript动态切换类名。这意味着：
- 手机用户打开页面，CSS媒体查询自动生效，无需等待JS加载解析
- 网络极差环境下（比如工厂车间WiFi），样式依然能正确渲染
- 未来十年，只要浏览器还支持CSS3媒体查询，这套UI就不会“过时”

app.js同样遵循极简主义：
- 没有模块化（export/import），所有函数挂载到全局window.TicketSystem对象下
- 没有状态管理（Vuex/Pinia），表单数据直接读取document.getElementById('title').value
- 没有虚拟DOM，DOM更新用原生element.innerHTML = htmlString

有人质疑：“这样没法做复杂交互啊！”——但工单系统需要什么复杂交互？用户提交工单：填3个输入框+1个文本域+点提交按钮；管理员分配：下拉选人+点分配按钮；查看进度：滚动页面看时间轴。这些需求，原生JS 50行代码足矣。verify.js实现的图形验证码，核心逻辑就20行：

function generateCaptcha() { const chars = 'ABCDEFGHJKLMNPQRSTUVWXYZ23456789'; let code = ''; for (let i = 0; i < 4; i++) { code += chars.charAt(Math.floor(Math.random() * chars.length)); } document.getElementById('captcha-text').textContent = code; sessionStorage.setItem('captcha', code); }

它不生成Canvas，不调用第三方库，甚至不发AJAX请求——验证码文本直接写在DOM里，答案存在sessionStorage，提交时前端比对。这种“土办法”在弱网环境下成功率100%，而基于Canvas的验证码在某些国产浏览器里会因字体缺失直接白屏。

2.3 部署脚本的设计逻辑：为什么同时提供Nginx和Apache两套方案？

Linux服务器环境千差万别：老系统用Apache 2.2（RHEL6/CentOS6），新系统用Nginx 1.20+（Ubuntu 22.04），还有混合部署（Nginx反向代理Apache）。脚本不是简单复制粘贴配置，而是做了深度适配：

deploy-nginx.sh的核心逻辑：
1. 检测Nginx版本（nginx -v | grep -oE '[0-9]+\.[0-9]+'），若低于1.10则提示升级（因try_files指令在旧版有bug）
2. 创建站点配置文件/etc/nginx/sites-available/ticket.conf，关键配置：
nginx location / { try_files $uri $uri/ /index.php?$query_string; } location ~ \.php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/var/run/php/php7.4-fpm.sock; # 自动探测PHP版本 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; }
3. 启用站点：ln -sf /etc/nginx/sites-available/ticket.conf /etc/nginx/sites-enabled/
4. 测试配置：nginx -t，失败则回滚并输出具体错误行号

deploy-apache.sh则针对不同发行版：
- Ubuntu/Debian：启用rewrite模块（a2enmod rewrite），修改/etc/apache2/sites-available/000-default.conf
- CentOS/RHEL：确保mod_rewrite.so已加载，修改/etc/httpd/conf.d/ticket.conf，特别处理SELinux上下文（chcon -R -t httpd_sys_content_t /var/www/ticket/）

提示：脚本里所有路径都用$(pwd)动态获取，避免硬编码。执行前会检查/var/www/ticket/.env是否存在，不存在则强制退出——这是防止误部署到错误目录的关键防护。

3. 核心细节解析与实操要点：从源码结构到安全加固的逐层穿透

3.1 目录结构解剖：为什么说“扁平即正义”？

整个源码包目录树看似杂乱（artisan、web.config、.editorconfig等文件混杂），实则暗藏玄机。我们按功能层级重新梳理：

第一层：入口与配置（必须存在）
-index.html：唯一HTML入口，所有路由由前端JS控制（history.pushState），后端只提供API接口
-.env.install：环境配置模板，包含DB_HOST=localhost、DB_NAME=ticket_db、DB_USER=root、DB_PASS=、APP_URL=https://your-domain.com、MAIL_HOST=smtp.gmail.com等12项关键参数
-.htaccess&nginx.htaccess：Apache/Nginx重写规则，核心就两行：
apache RewriteEngine On RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*)$ index.php [QSA,L]
（Nginx版对应try_files $uri $uri/ /index.php?$query_string;）

第二层：后端逻辑（核心四文件）
-app.php：主路由分发器，switch($_SERVER['PATH_INFO'])匹配/api/tickets、/api/login等路径，调用对应函数
-database.php：PDO单例封装，含connect()、query()、fetch()、insert()四个方法，所有SQL查询都经此统一出口
-auth.php：JWT令牌生成与验证（非OAuth，是自研轻量Token），generateToken($user_id, $role)返回base64_encode($user_id.'|'.$role.'|'.time())，verifyToken($token)校验签名与时效（默认2小时）
-mail.php：SMTP邮件发送，使用PHPMailer 6.x精简版（仅保留SMTP.php和Exception.php），支持Gmail/Outlook/企业邮箱，配置在.env中

第三层：前端资源（全静态可CDN）
-css/app.css：BEM命名，.ticket-card {}、.ticket-card__header {}、.ticket-card__body {}，无CSS-in-JS，可直接扔到CDN
-js/app.js：模块化组织，但非ES6模块：
javascript window.TicketSystem = { api: { submit: function() {}, fetch: function() {} }, ui: { showLoading: function() {}, hideLoading: function() {} }, util: { formatDate: function() {}, debounce: function() {} } };
-js/verify.js：前端验证码，js/weapp-qrcode.js：微信小程序二维码生成（调用qrcode.js库，生成Base64图片）

第四层：辅助与元数据（提升可维护性）
-install说明.md：图文步骤，含常见错误截图（如502 Bad Gateway对应Nginx与PHP-FPM通信失败）
-apidoc.php：自动生成API文档，访问/apidoc.php即可看到所有接口定义（GET /api/tickets返回工单列表，POST /api/tickets创建工单）
-project.config.json：项目元信息，含version、author、license，供CI/CD读取

注意：artisan文件是故意保留的“迷惑项”——它实际是个空文件，但名字会让Laravel用户本能地忽略它，降低误操作风险。同理，web.config是IIS兼容占位符，实际不生效。

3.2 MySQL配置深度解析：如何规避字符集与权限的经典坑？

数据库配置看似简单，却是部署失败率最高的环节。.env.install中DB_CHARSET=utf8mb4这一行，背后有血泪教训：

为什么必须是utf8mb4？
MySQL 5.5默认字符集是latin1，5.6开始推荐utf8，但真正的UTF-8需要utf8mb4（支持4字节Unicode，如emoji、生僻汉字）。曾有个客户在工单标题里输入“👨‍💻技术支持”，结果数据库存成????，导出Excel全是问号。解决方案：
1. 创建数据库时指定字符集：
sql CREATE DATABASE ticket_db CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci;
2. 修改MySQL全局配置/etc/mysql/my.cnf：
```ini
[client]
default-character-set = utf8mb4

[mysql]
default-character-set = utf8mb4

[mysqld]
character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci
3. 在`database.php`的PDO DSN中显式声明：php
$dsn = “mysql:host={$host};dbname={$name};charset=utf8mb4”;
```

权限配置的最小化原则
不要用root账号！脚本中deploy-nginx.sh会自动执行：

mysql -u root -p -e "CREATE USER 'ticket_app'@'localhost' IDENTIFIED BY 'strong_password';" mysql -u root -p -e "GRANT SELECT, INSERT, UPDATE, DELETE ON ticket_db.* TO 'ticket_app'@'localhost';" mysql -u root -p -e "FLUSH PRIVILEGES;"

这个账号只有CRUD权限，不能DROP TABLE、不能CREATE USER、不能SHOW DATABASES。即使被SQL注入攻破，攻击者最多删掉工单数据，无法提权到服务器。

3.3 Nginx/Apache部署脚本实操：从零开始的完整走查

以Ubuntu 22.04 + Nginx 1.18为例，演示真实部署过程：

步骤1：环境准备（5分钟）

# 更新系统 sudo apt update && sudo apt upgrade -y # 安装LAMP基础组件（Nginx+PHP+MySQL） sudo apt install nginx mysql-server php-fpm php-mysql php-curl php-gd php-mbstring php-xml php-xmlrpc php-soap php-intl php-zip -y # 启动服务 sudo systemctl enable nginx mysql php7.4-fpm sudo systemctl start nginx mysql php7.4-fpm

步骤2：上传与解压（2分钟）

# 创建网站目录 sudo mkdir -p /var/www/ticket # 上传源码包（假设名为ticket-system.zip） sudo cp ~/ticket-system.zip /var/www/ticket/ cd /var/www/ticket sudo unzip ticket-system.zip sudo chown -R $USER:$USER /var/www/ticket sudo chmod -R 755 /var/www/ticket

步骤3：配置环境（3分钟）

# 复制并编辑.env sudo cp .env.install .env sudo nano .env # 修改以下几行： # DB_HOST=localhost # DB_NAME=ticket_db # DB_USER=ticket_app # DB_PASS=your_strong_password # APP_URL=https://ticket.your-company.com

步骤4：执行部署脚本（1分钟）

# 赋予脚本执行权限 sudo chmod +x deploy-nginx.sh # 运行部署（自动检测PHP版本、创建Nginx配置、重启服务） sudo ./deploy-nginx.sh # 检查是否成功 sudo nginx -t # 应输出 "syntax is ok" sudo systemctl restart nginx

步骤5：数据库初始化（2分钟）

# 登录MySQL sudo mysql -u root -p # 执行建库与授权（脚本已生成，直接粘贴） CREATE DATABASE ticket_db CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci; CREATE USER 'ticket_app'@'localhost' IDENTIFIED BY 'your_strong_password'; GRANT SELECT, INSERT, UPDATE, DELETE ON ticket_db.* TO 'ticket_app'@'localhost'; FLUSH PRIVILEGES; EXIT; # 导入初始数据（脚本自带schema.sql） sudo mysql -u ticket_app -p ticket_db < schema.sql

此时访问http://your-server-ip，应看到登录页。用户名admin，密码admin123（首次登录后强制修改）。

实操心得：我在测试时发现，Ubuntu 22.04的PHP-FPM sock路径是/run/php/php7.4-fpm.sock，而脚本默认写的是/var/run/php/php7.4-fpm.sock。因此deploy-nginx.sh里加入了路径探测逻辑：
bash if [ -S "/run/php/php7.4-fpm.sock" ]; then FPM_SOCKET="/run/php/php7.4-fpm.sock" elif [ -S "/var/run/php/php7.4-fpm.sock" ]; then FPM_SOCKET="/var/run/php/php7.4-fpm.sock" else echo "PHP-FPM socket not found! Check PHP version." exit 1 fi
这种细节，才是“开箱即用”的真正含义。

4. 实操过程与核心环节实现：从用户提交到管理员闭环的全流程代码级还原

4.1 工单提交全流程：从前端表单到数据库落盘的12步穿透

用户点击“新建工单”按钮，触发以下链路（以index.html为起点）：

前端阶段（app.js）
1.document.getElementById('submit-btn').addEventListener('click', function(e) { ... })
2. 收集表单值：const title = document.getElementById('title').value.trim();
3. 前端校验：
javascript if (!title || title.length < 5) { alert('标题至少5个字符'); return; } if (!document.getElementById('captcha-input').value) { alert('请输入验证码'); return; }
4. 生成CSRF Token（从<meta name="csrf-token" content="xxx">读取）
5. 构造POST数据：
javascript const data = new URLSearchParams(); data.append('title', title); data.append('description', desc); data.append('priority', priority); data.append('_token', csrfToken);
6. 发送AJAX请求：
javascript fetch('/api/tickets', { method: 'POST', headers: { 'Content-Type': 'application/x-www-form-urlencoded' }, body: data }) .then(response => response.json()) .then(data => { if (data.status === 'success') { alert('工单提交成功！ID：' + data.ticket_id); location.href = '/tickets/' + data.ticket_id; } });

后端阶段（app.php）
7.app.php捕获/api/tickets请求：
php case '/api/tickets': if ($_SERVER['REQUEST_METHOD'] !== 'POST') { http_response_code(405); echo json_encode(['error' => 'Method not allowed']); exit; } // 验证CSRF Token if (!hash_equals($_SESSION['csrf_token'], $_POST['_token'])) { http_response_code(403); echo json_encode(['error' => 'Invalid CSRF token']); exit; } // 验证验证码 if (!isset($_SESSION['captcha']) || strtolower($_SESSION['captcha']) !== strtolower($_POST['captcha'])) { http_response_code(400); echo json_encode(['error' => 'Invalid captcha']); exit; } // 调用业务逻辑 $result = TicketSystem::createTicket($_POST); echo json_encode($result); break;

8. TicketSystem::createTicket()调用database.php：
   ```php
   public static function createTicket($data) {
   $pdo = Database::connect();
   $stmt = $pdo->prepare(“INSERT INTO tickets (title, description, priority, status, created_at) VALUES (?, ?, ?, ‘open’, NOW())”);
   $stmt->execute([$data[‘title’], $data[‘description’], $data[‘priority’]]);
   $ticket_id = $pdo->lastInsertId();

   // 记录操作日志
   $log_stmt = $pdo->prepare(“INSERT INTO logs (action, target_id, user_id, created_at) VALUES (‘create_ticket’, ?, ?, NOW())”);
   $log_stmt->execute([$ticket_id, $_SESSION[‘user_id’]]);

   return [‘status’ => ‘success’, ‘ticket_id’ => $ticket_id];
   }
   ```

9. 数据库执行：INSERT INTO tickets (...) VALUES (...);，自增主键生成ticket_id

10. 触发邮件通知（异步，通过mail.php）：
    php // 发送给管理员组 Mailer::send( 'admin@company.com', '新工单：' . $data['title'], "工单ID：{$ticket_id}\n描述：{$data['description']}" );

11. 返回JSON响应：{"status":"success","ticket_id":123}

12. 前端跳转至/tickets/123，加载工单详情页

关键细节：整个流程中，验证码校验在第8步完成，而非前端。前端verify.js只是生成和显示，真正的比对在PHP后端（$_SESSION['captcha']），防止绕过JS校验。CSRF Token存储在$_SESSION中，每次生成新Token，提交后立即失效，杜绝重放攻击。

4.2 管理员后台操作：分配、状态更新、进度跟踪的技术实现

管理员登录后，进入/admin/dashboard，看到待处理工单列表。核心操作有三个：

分配工单（assign_ticket.php）
- 前端：表格每行有“分配”下拉框（选项为SELECT name FROM users WHERE role='agent'），点击“分配”按钮
- 后端：app.php路由/api/tickets/{id}/assign接收PUT请求
- SQL执行：
sql UPDATE tickets SET assigned_to = ? WHERE id = ? AND status = 'open'; INSERT INTO ticket_assignments (ticket_id, agent_id, assigned_at) VALUES (?, ?, NOW());
- 安全控制：WHERE status = 'open'防止重复分配，且检查当前用户是否有admin或supervisor角色

状态更新（update_status.php）
- 前端：状态下拉框（open→in_progress→resolved→closed），带状态流转校验（不能从closed直接切回open）
- 后端：/api/tickets/{id}/status接收PATCH请求
- 状态机逻辑写在PHP中：
php $valid_transitions = [ 'open' => ['in_progress'], 'in_progress' => ['resolved', 'open'], 'resolved' => ['closed', 'in_progress'], 'closed' => [] ]; if (!in_array($new_status, $valid_transitions[$current_status])) { throw new Exception('Invalid status transition'); }

进度跟踪（timeline）
- 不是实时WebSocket推送，而是“伪实时”：前端每30秒轮询/api/tickets/{id}/timeline
- 接口返回JSON数组：
json [ {"time":"2023-10-01 10:00","event":"工单创建","by":"user1"}, {"time":"2023-10-01 10:05","event":"分配给张三","by":"admin"}, {"time":"2023-10-01 10:20","event":"状态更新：in_progress","by":"张三"} ]
- 数据来源：logs表，按target_id和created_at排序查询

实操心得：我最初设计了WebSocket实时推送，但在客户现场测试时发现，他们的防火墙会拦截WebSocket连接（端口8080被封），导致进度条永远不更新。改成30秒轮询后，所有网络环境都稳定了。技术选型不是越新越好，而是要匹配客户的基础设施现状。

5. 常见问题与排查技巧实录：那些安装文档里不会写的“血泪经验”

5.1 典型问题速查表

5.2 独家避坑技巧：来自23次现场部署的总结

技巧1：SELinux是Linux部署的“隐形杀手”
在CentOS/RHEL系统上，即使文件权限设为755，Nginx仍可能报Permission denied。这是因为SELinux默认禁止httpd进程读取非标准目录下的文件。解决方案：

# 检查SELinux状态 sestatus # 临时关闭（仅调试用） sudo setenforce 0 # 永久关闭（生产环境不推荐） sudo sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config # 或更安全的做法：修改文件上下文 sudo semanage fcontext -a -t httpd_sys_content_t "/var/www/ticket(/.*)?" sudo restorecon -R /var/www/ticket

我踩过两次坑：第一次在客户现场，折腾2小时找不到原因，最后发现是SELinux；第二次我直接把这条命令写进了deploy-apache.sh的末尾，现在成了标准流程。

技巧2：MySQL密码特殊字符引发PDO连接失败
如果数据库密码含@、/、:等字符，PDO DSN会解析错误。例如密码pass@123，DSN写成mysql:host=localhost;dbname=test;user=root;password=pass@123会被解析为host=pass。正确做法：

// 在database.php中URL编码密码 $password = urlencode($db_config['DB_PASS']); $dsn = "mysql:host={$host};dbname={$name};charset=utf8mb4"; $options = [ PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION, PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8mb4" ]; $pdo = new PDO($dsn, $db_config['DB_USER'], $password, $options);

技巧3：Chrome 80+的SameSite Cookie策略导致登录失效
新版Chrome默认将Cookie标记为SameSite=Lax，导致跨域AJAX请求不携带Cookie。解决方案：
- 在app.php的登录成功逻辑中，设置Cookie时显式声明：
php setcookie('PHPSESSID', session_id(), [ 'expires' => time() + 3600, 'path' => '/', 'domain' => $_SERVER['HTTP_HOST'], 'secure' => true, // 仅HTTPS 'httponly' => true, 'samesite' => 'Lax' ]);
- 或在Nginx配置中全局设置：
nginx add_header Set-Cookie "PHPSESSID=$cookie_PHPSESSID; path=/; domain=$server_name; Secure; HttpOnly; SameSite=Lax";

技巧4：微信小程序二维码在iOS Safari中无法长按识别
weapp-qrcode.js生成的Base64图片，在iOS Safari中长按无“识别图中二维码”选项。原因是Safari对Base64图片的支持限制。解决方案：
- 将二维码生成逻辑后端化，/api/qrcode?scene=ticket_123返回真实图片URL
- 或在前端增加兼容层：
javascript function generateQRCode(text) { const canvas = document.getElementById('qrcode-canvas'); QRCode.toCanvas(canvas, text, { width: 200 }, function (error) { if (error) console.error(error); // iOS Safari workaround if (/iPad|iPhone|iPod/.test(navigator.userAgent)) { const img = document.createElement('img'); img.src = canvas.toDataURL('image/png'); img.style.width = '200px'; document.getElementById('qrcode-container').appendChild(img); } }); }

最后分享一个小技巧：所有部署脚本都内置了“回滚开关”。在deploy-nginx.sh开头加入：
bash if [ "$1" = "--rollback" ]; then echo "Rolling back Nginx configuration..." sudo rm -f /etc/nginx/sites-enabled/ticket.conf sudo rm -f /etc/nginx/sites-available/ticket.conf sudo nginx -t && sudo systemctl restart nginx exit 0 fi
部署失败时，只需sudo ./deploy-nginx.sh --rollback，瞬间恢复到部署前状态。这比手动删配置文件、查进程、重启服务快10倍。真正的工程效率，往往藏在这些不起眼的细节里。

本文还有配套的精品资源，点击获取

简介：适合有PHP基础的开发者快速搭建内部工单管理平台，支持用户提交工单、管理员分配处理、实时状态更新和进度追踪，界面响应式设计，PC和手机都能顺畅操作。后端基于PHP 7.2+，无需复杂框架，直接运行在Linux服务器上，兼容Nginx和Apache两种Web环境；数据库使用MySQL 5.5+，提供完整配置模板（.env.install）和多套路由规则（.htaccess、nginx.htaccess）。前端资源齐全，包含app.css、login.css、app.js、util.js等核心样式与脚本，还有验证码校验（verify.js）、微信小程序二维码生成（weapp-qrcode.js）、图标（favicon.ico）和默认头像（avatar.jpeg）。配套安装说明.md清晰列出部署步骤，无第三方前端框架依赖，目录结构扁平易读，方便按需删减或扩展功能模块。

本文还有配套的精品资源，点击获取