尧图网页设计 
简介信呼协同办公OA系统 v1.8.6 是一套开源的企业办公解决方案面向需要跨平台协同的中小企业及开发者覆盖日常审批、任务管理、即时通讯等场景。该版本在上一版基础上优化了系统稳定性与移动端体验支持PC、Web及手机APP多端使用员工在外出差或远程工作时也能便捷处理流程和查阅文件。资源包共1248个文件约2.79MB以PHP后端逻辑、HTML页面、JS交互脚本及CSS样式为主并包含GIF/PNG图标素材与SQL数据库脚本便于完整部署与二次开发。系统内置工作流引擎、任务管理、日程安排、文件管理、即时通讯、公告通知、人事考勤等模块同时提供多重加密与权限管理机制保障企业敏感数据安全。源码目录结构清晰适合需要快速搭建OA系统或研究PHP协同办公架构的开发者可结合自身业务流程灵活定制功能模块。资源体积小巧部署快速已有317人学习下载。1. 信呼协同办公 OA 系统 v1.8.6 为什么还值得自己装一套前两周有个朋友公司的 OA 到期续费商业系统给出的报价让他们直接放弃了续约转头来问我开源方案能不能顶住日常办公。我把信呼协同办公 OA 系统 v1.8.6 部署到了一台 2 核 4G 的云服务器上跑审批、打卡、日报、会议纪要这些常用模块一周内整个团队就稳定用上了。相比动辄按年付费的商业 OA这类 PHP 开源系统最大的价值不是免费而是部署权在自己手里数据放自己的库登录时长自己定加字段加流程也不再被厂商报价卡住脖子。这篇就按我从部署到上线一路走下来的顺序把信呼 v1.8.6 的目录结构、初始化配置、审批流设置和常见故障一次说清楚。2. 信呼 v1.8.6 部署从源码包到能打开的登录页2.1 解包后的目录怎么读入口、配置、上传与缓存信呼 v1.8.6 是典型的 PHP 应用源码包解压后第一眼不要乱。先把目录里四类东西分清楚根目录入口文件、业务模块目录、runtime 缓存目录、upload 附件目录。入口文件一般是 index.php所有后台页面和接口最终都会汇集到这里业务模块目录负责具体功能比如审批、考勤、项目任务runtime 目录存编译模板和缓存改完配置或出现白屏时首先要清它upload 目录放上传的附件和图片正式上线前要给写权限。我第一次部署这类源码包时最容易犯的错是把 runtime 和 upload 搞混一看白屏就把整个目录权限改成 777权限问题暂时消失了但安全隐患留下了。其实正确的做法是先看 runtime 目录下有没有生成缓存文件再决定要不要动权限。目录结构读懂了后续定位问题至少能少走一半弯路。2.2 PHP 环境和扩展检查用两条命令筛掉八成问题信呼 v1.8.6 对运行环境的硬性要求不算苛刻但版本太低会直接在登录阶段翻车。我建议 PHP 7.4数据库用 MySQL 5.7 以上。PHP 8.0 以上高版本也能跑但部分老插件和函数兼容性需要多花时间调试。部署前先执行两条命令php -v php -m | grep -Ei pdo_mysql|mbstring|curl|gd|openssl第一条命令看 PHP 版本第二条检查五个关键扩展。信呼登录后会做加解密处理考勤和日报模块会用到 curl 抓取和 GD 绘图缺了 pdo_mysql 就直接连不上数据库。输出中如果缺少任何一项先补齐扩展再继续否则后续所有操作都建立在漏了轮子的地基上。2.3 导入数据库并改写连接配置四个参数定生死源码包一般会带一个 SQL 安装文件名字可能是 install.sql 或 xinhu.sql我建议先建库再导入。数据库字符集直接指定 utf8mb4否则中文内容在后期跨环境迁移时会遇到排序规则冲突。mysql -uroot -p -e CREATE DATABASE xinhu DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; mysql -uroot -p --default-character-setutf8mb4 xinhu install.sql第二条命令里的--default-character-setutf8mb4是关键。如果漏了而 MySQL 服务端默认字符集是 latin1导入过程中字段会显示正常但后台搜索中文时会出现“数据在库里却查不到”的诡异现象。这类问题最容易让人怀疑自己的代码逻辑实际上是字符集在导入阶段就错了。导入完成后找到配置文件把数据库连接改成当前环境的值。通常需要确认 host、name、user、pwd 四个参数写错一个系统就起不来。// 数据库连接配置改完记得清空 runtime 缓存 db [ host 127.0.0.1, name xinhu, user root, pwd 你的数据库密码, charset utf8mb4, ],如果你的数据库跑在 Docker 里或者独立云数据库上host 不要写 localhost要写内网 IP否则 PHP 会走 Unix socket 而不是 TCP 连接报错也会更隐蔽。这个配置改完通常还需要把 runtime 目录清理一次才能确保新配置被正常加载。2.4 先跑起来再谈配置用 PHP 内置服务器验证登录页环境配齐后我先不建议立刻去配 Nginx。开发机上用 PHP 内置服务器把页面拉起来验证整体链路通不通是最快的做法。php -S 127.0.0.1:8080 -t /srv/xinhu直接执行这条命令能访问首页但信呼带路由后台菜单的深链接会 404。所以我会加一个 router.php让内置服务器把非静态请求送到入口文件。php -S 127.0.0.1:8080 -t /srv/xinhu /srv/xinhu/router.phprouter.php 的逻辑只有十几行?php // router.php让全部非静态请求进入 index.php $path parse_url($_SERVER[REQUEST_URI], PHP_URL_PATH); $file __DIR__ . $path; if ($path ! / file_exists($file) !is_dir($file)) { return false; // 真实存在的文件交还给服务器输出 } require __DIR__ . /index.php;这个文件只是模拟 Nginx 的 try_files避免为了本地验证还得先设计一套完整伪静态配置。内置服务器能打开登录页就说明数据库连接、PHP 扩展、配置项都没问题。至于初始管理员账号以你下载包里的 README 或 install.sql 中 insert 语句为准一般安装完第一次登录会强制改密。2.5 换到 Nginx/Apache 时的路由重写与伪静态内置服务器验证通过后要上正式环境就得换回 Nginx。如果只配置 PHP 解析不管路由重写你会看到首页能打开但登录成功后地址栏路径变成 404。location / { try_files $uri $uri/ /index.php?$query_string; } location ~ \.php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; }try_files那一行是核心它负责把找不到的 URI 交给 index.php 处理。漏掉这段配置信呼后台几乎所有的深链接路由都会失效。如果你用 Apache就等价地开 mod_rewrite 并放置 .htaccess。这里没有玄学只是很多人上线后只测首页不测二级页面最后被菜单页 404 坑到才回头查伪静态。3. 把审批流配出来角色、菜单权限和流程节点怎么串3.1 权限三件套部门、角色、管理员分别管什么信呼 v1.8.6 的权限模型可以拆成三个概念部门管组织架构角色管菜单可见性和操作权限管理员账号就是具体的人或者对接系统的接口账号。很多人配置审批流时总盯着“流程”看忽略了前两步角色有没有绑定对应部门管理员账号有没有分配角色。这三个错位审批单提交后就会卡在“处理人不存在”的状态。以请假申请为例部门负责人审批的前提是“部门经理”这个角色负责的部门范围里包含申请人的部门HR 审批的前提是 HR 角色绑定了所有部门的审批可见范围。这两个前提缺一不可不是单纯在流程图上画两个节点就行。3.2 配一个审批流从新增单类型到设置审核节点后台配置页一般分两层先建“单据类型”再配“审核流程”。单据类型定义这张单要填什么字段审核流程定义这些字段值由谁处理、在什么条件下跳转。先加一张请假单字段至少包含开始时间、结束时间、请假事由、请假天数。保存后系统会生成对应的单据 ID后续流程节点都挂在这个 ID 上。为了方便看清流程节点的本质下面用一段描述配置结果的代码来表达它是后台保存后内存里的逻辑结构不是让你直接覆盖进项目// 审批流节点结构后台配置后的效果示意 $flow [ title 请假申请, steps [ [ operator dept_manage, // 部门经理 action approve, // 审批 timeout 24 * 3600, // 24小时未处理 timeout_action auto_pass,// 自动审批通过 ], [ operator hr_manage, // HR经理 action approve, timeout 48 * 3600, timeout_action auto_remind, // 只提醒不自动处理 ], ], condition [ field leave_days, op , value 3, // 请假超过3天才走HR确认 ], ];这段结构的重点在于审批流不是一条直线而是带条件判断的。你在后台添加“请假超过 3 天需要 HR 确认”之类规则时系统背后就是在流程节点的 condition 里写了一个比较表达式。理解了这个模型你再去看后台那些“新增条件”“添加分支”按钮思路会清晰很多。3.3 验证审批流后台模拟提交和脚本检查待办配置完审批流不能只在界面看看要真实提交一张请假单用另一个测试账号登录查看待办。信呼的待办逻辑会按照 operator 字段去匹配当前用户角色如果角色不匹配单子会卡在“无处理人”上后台不报错但也走不下去。这一步我会用一个命令行小脚本去调待办查询接口确认数据从表单走到了待办表。假设包内有 cli.php 这类入口执行是这样的php cli.php test/get-todo --userid1001如果包内没有对应入口可以写个一次性 PHP 脚本加载入口文件后调用待办方法。脚本的目的不是刷日志而是完成闭环验证提交单子检查待办模拟审批最后查看状态。这一步走过去才说明流程节点真的被系统接收了而不是只在配置页面上显示好看。4. 信呼 v1.8.6 上线避坑5 个部署期必踩的坑与排查手段4.1 登录后白屏或 500PHP 扩展缺失和缓存叠加现象安装向导走完数据库导入成功输入管理员账号登录后页面空白Nginx 的 error.log 里出现Class PDO not found或者Undefined function mb_substr。原因PHP 版本环境换了但 pdo_mysql 和 mbstring 扩展没装。另一个叠加因素是 runtime 缓存里残留旧信息导致新代码没生效。解决先补扩展再检查缓存。sudo apt install php7.4-mysql php7.4-mbstring php7.4-curl php7.4-gd php -m | grep pdo_mysql重启 PHP-FPM 后清空 runtime 目录里生成的文件只保留目录本身。这两步做完白屏基本消除。如果还白就打开 PHP 的 display_errors 看真实报错不再盲目改权限。4.2 数据库导入失败或中文乱码字符集和排序规则打架现象执行mysql xinhu install.sql时报Unknown collation utf8mb4_0900_ai_ci或者导入成功但后台搜索中文查不到。原因SQL 文件来自 MySQL 8.0 导出带着 utf8mb4_0900_ai_ci 排序规则而目标库是 MySQL 5.7不认识这个规则。字符集不匹配则会在索引和比较时出现不一致。解决替换排序规则后继续导入。sed -i s/utf8mb4_0900_ai_ci/utf8mb4_unicode_ci/g install.sql mysql -uroot -p --default-character-setutf8mb4 xinhu install.sql这里要记住导入前先确认目标库版本不要等报错再排查。这个坑的隐蔽性在于导入失败是显性报错替换后数据看起来正常但中文搜索问题会在上线后爆发到时候你要排查的范围更大。4.3 打卡记录时间慢 8 小时PHP 时区没配置现象系统首页时间正常但考勤打卡记录显示的时间总比实际时间晚 8 小时排班逻辑也跟着错位。原因PHP 默认时区是 UTC数据库连接后写入的时间也是 UTC某些报表接口没有再做一次时区转换导致只有部分模块时间不准。解决把 PHP 时区和平台时区配置都改成 Asia/Shanghai。date.timezone Asia/Shanghai改完重启 PHP-FPM再清一次 runtime 缓存。现有历史数据如果已经写错只能做数据订正不影响后续打卡记录。上线前用测试账号打一次卡比上线后人工改数据省事得多。4.4 附件上传报错或提示 413上传限制在三个地方现象上传一份 20MB 的文件被拒页面上提示 413 Request Entity Large或者直接报“上传失败”但没任何原因。原因Nginx 的 client_max_body_size、PHP 的 upload_max_filesize、post_max_size 三个值不一致。Nginx 先拦截大请求PHP 再拦一次任何一个不够都会失败。解决三层一起调。client_max_body_size 50m;upload_max_filesize 50M post_max_size 50M重启 Nginx 和 PHP-FPM。然后检查 upload 目录对 PHP 运行用户是否可写chown -R www-data:www-data upload/ chmod -R 755 upload/我不建议给 777 权限。权限问题的正确解法是让运行用户拥有目录而不是让所有人都能写。777 在出问题时会让日志里看不出是谁写的安全上也很难收场。4.5 登录时长形同虚设会话生命周期和在线判定不一致现象外网用户登录 OA挂机不到半小时就被踢回登录页另一些账号挂一天也不会掉线安全策略完全失控。原因PHP 的 session.gc_maxlifetime 和 session.cookie_lifetime 不一致或者会话存放在 Redis/MemcachedGC 回收策略由服务端配置决定PHP 里的设置就不会生效。解决先把两组会话参数对齐。session.gc_maxlifetime 7200 session.cookie_lifetime 0cookie_lifetime 设为 0 表示浏览器关闭时失效这是最安全的做法。如果公司习惯常驻登录就把两个参数都设成 7200 秒再重启 PHP-FPM 做一次真实验证。登录时长这个问题留的越大账号暴露风险越高上线前就要按公司安全策略定下来。5. 调整登录时长与会话过期让 OA 的在线状态贴合公司习惯上一节讲的会话参数是基础真正把“登录时长”设置好还要分两层理解会话过期时间和前端心跳续期。很多人在后台只看到一个“有效时长”的输入框以为填个数字就完了实际上前端页面如果每 5 分钟自动发一个心跳请求那么会话会被无限续期后台填的 30 分钟形同虚设。反过来如果心跳机制关了用户正在编辑一封长邮件手一停就会掉线这也是问题。因此我建议按使用场景把登录时长拆成三档。场景session 过期时间前端心跳说明公司内网宽带8 小时5 分钟上班挂机不被频繁踢出外网/混合办公4 小时5 分钟平衡安全与便利访客或供应商账号本次会话关闭无心跳浏览器关闭即失效我一般会在后端配置里把这三个档位写成常量然后让后台页面的选择项去读常量而不是让运维人员直接在代码里改 session 配置。这样谁调整了登录时长改成多少都能够在系统日志里留下痕迹。登录时长的本质是一次安全策略选择你能容忍的便利程度决定了账号在暴露状态下能停留多久。最后说个我自己的教训。早前有个项目为了减少同事抱怨我把管理员账号的过期时间设成 12 小时又开着 5 分钟心跳。结果是某个离职员工的老账号在三个月后依然能登录后台被发现时差点出大问题。后来我强迫自己养成了一个习惯所有外部协作账号单独建角色会话过期时间强制 4 小时心跳关闭。这个做法沿用到现在至少没再出过类似事故。希望帮到你。本文还有配套的精品资源点击获取 信呼开源OA v1.8.6部署指南：环境配置、审批流与会话时长调优
简介信呼协同办公OA系统 v1.8.6 是一套开源的企业办公解决方案面向需要跨平台协同的中小企业及开发者覆盖日常审批、任务管理、即时通讯等场景。该版本在上一版基础上优化了系统稳定性与移动端体验支持PC、Web及手机APP多端使用员工在外出差或远程工作时也能便捷处理流程和查阅文件。资源包共1248个文件约2.79MB以PHP后端逻辑、HTML页面、JS交互脚本及CSS样式为主并包含GIF/PNG图标素材与SQL数据库脚本便于完整部署与二次开发。系统内置工作流引擎、任务管理、日程安排、文件管理、即时通讯、公告通知、人事考勤等模块同时提供多重加密与权限管理机制保障企业敏感数据安全。源码目录结构清晰适合需要快速搭建OA系统或研究PHP协同办公架构的开发者可结合自身业务流程灵活定制功能模块。资源体积小巧部署快速已有317人学习下载。1. 信呼协同办公 OA 系统 v1.8.6 为什么还值得自己装一套前两周有个朋友公司的 OA 到期续费商业系统给出的报价让他们直接放弃了续约转头来问我开源方案能不能顶住日常办公。我把信呼协同办公 OA 系统 v1.8.6 部署到了一台 2 核 4G 的云服务器上跑审批、打卡、日报、会议纪要这些常用模块一周内整个团队就稳定用上了。相比动辄按年付费的商业 OA这类 PHP 开源系统最大的价值不是免费而是部署权在自己手里数据放自己的库登录时长自己定加字段加流程也不再被厂商报价卡住脖子。这篇就按我从部署到上线一路走下来的顺序把信呼 v1.8.6 的目录结构、初始化配置、审批流设置和常见故障一次说清楚。2. 信呼 v1.8.6 部署从源码包到能打开的登录页2.1 解包后的目录怎么读入口、配置、上传与缓存信呼 v1.8.6 是典型的 PHP 应用源码包解压后第一眼不要乱。先把目录里四类东西分清楚根目录入口文件、业务模块目录、runtime 缓存目录、upload 附件目录。入口文件一般是 index.php所有后台页面和接口最终都会汇集到这里业务模块目录负责具体功能比如审批、考勤、项目任务runtime 目录存编译模板和缓存改完配置或出现白屏时首先要清它upload 目录放上传的附件和图片正式上线前要给写权限。我第一次部署这类源码包时最容易犯的错是把 runtime 和 upload 搞混一看白屏就把整个目录权限改成 777权限问题暂时消失了但安全隐患留下了。其实正确的做法是先看 runtime 目录下有没有生成缓存文件再决定要不要动权限。目录结构读懂了后续定位问题至少能少走一半弯路。2.2 PHP 环境和扩展检查用两条命令筛掉八成问题信呼 v1.8.6 对运行环境的硬性要求不算苛刻但版本太低会直接在登录阶段翻车。我建议 PHP 7.4数据库用 MySQL 5.7 以上。PHP 8.0 以上高版本也能跑但部分老插件和函数兼容性需要多花时间调试。部署前先执行两条命令php -v php -m | grep -Ei pdo_mysql|mbstring|curl|gd|openssl第一条命令看 PHP 版本第二条检查五个关键扩展。信呼登录后会做加解密处理考勤和日报模块会用到 curl 抓取和 GD 绘图缺了 pdo_mysql 就直接连不上数据库。输出中如果缺少任何一项先补齐扩展再继续否则后续所有操作都建立在漏了轮子的地基上。2.3 导入数据库并改写连接配置四个参数定生死源码包一般会带一个 SQL 安装文件名字可能是 install.sql 或 xinhu.sql我建议先建库再导入。数据库字符集直接指定 utf8mb4否则中文内容在后期跨环境迁移时会遇到排序规则冲突。mysql -uroot -p -e CREATE DATABASE xinhu DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; mysql -uroot -p --default-character-setutf8mb4 xinhu install.sql第二条命令里的--default-character-setutf8mb4是关键。如果漏了而 MySQL 服务端默认字符集是 latin1导入过程中字段会显示正常但后台搜索中文时会出现“数据在库里却查不到”的诡异现象。这类问题最容易让人怀疑自己的代码逻辑实际上是字符集在导入阶段就错了。导入完成后找到配置文件把数据库连接改成当前环境的值。通常需要确认 host、name、user、pwd 四个参数写错一个系统就起不来。// 数据库连接配置改完记得清空 runtime 缓存 db [ host 127.0.0.1, name xinhu, user root, pwd 你的数据库密码, charset utf8mb4, ],如果你的数据库跑在 Docker 里或者独立云数据库上host 不要写 localhost要写内网 IP否则 PHP 会走 Unix socket 而不是 TCP 连接报错也会更隐蔽。这个配置改完通常还需要把 runtime 目录清理一次才能确保新配置被正常加载。2.4 先跑起来再谈配置用 PHP 内置服务器验证登录页环境配齐后我先不建议立刻去配 Nginx。开发机上用 PHP 内置服务器把页面拉起来验证整体链路通不通是最快的做法。php -S 127.0.0.1:8080 -t /srv/xinhu直接执行这条命令能访问首页但信呼带路由后台菜单的深链接会 404。所以我会加一个 router.php让内置服务器把非静态请求送到入口文件。php -S 127.0.0.1:8080 -t /srv/xinhu /srv/xinhu/router.phprouter.php 的逻辑只有十几行?php // router.php让全部非静态请求进入 index.php $path parse_url($_SERVER[REQUEST_URI], PHP_URL_PATH); $file __DIR__ . $path; if ($path ! / file_exists($file) !is_dir($file)) { return false; // 真实存在的文件交还给服务器输出 } require __DIR__ . /index.php;这个文件只是模拟 Nginx 的 try_files避免为了本地验证还得先设计一套完整伪静态配置。内置服务器能打开登录页就说明数据库连接、PHP 扩展、配置项都没问题。至于初始管理员账号以你下载包里的 README 或 install.sql 中 insert 语句为准一般安装完第一次登录会强制改密。2.5 换到 Nginx/Apache 时的路由重写与伪静态内置服务器验证通过后要上正式环境就得换回 Nginx。如果只配置 PHP 解析不管路由重写你会看到首页能打开但登录成功后地址栏路径变成 404。location / { try_files $uri $uri/ /index.php?$query_string; } location ~ \.php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; }try_files那一行是核心它负责把找不到的 URI 交给 index.php 处理。漏掉这段配置信呼后台几乎所有的深链接路由都会失效。如果你用 Apache就等价地开 mod_rewrite 并放置 .htaccess。这里没有玄学只是很多人上线后只测首页不测二级页面最后被菜单页 404 坑到才回头查伪静态。3. 把审批流配出来角色、菜单权限和流程节点怎么串3.1 权限三件套部门、角色、管理员分别管什么信呼 v1.8.6 的权限模型可以拆成三个概念部门管组织架构角色管菜单可见性和操作权限管理员账号就是具体的人或者对接系统的接口账号。很多人配置审批流时总盯着“流程”看忽略了前两步角色有没有绑定对应部门管理员账号有没有分配角色。这三个错位审批单提交后就会卡在“处理人不存在”的状态。以请假申请为例部门负责人审批的前提是“部门经理”这个角色负责的部门范围里包含申请人的部门HR 审批的前提是 HR 角色绑定了所有部门的审批可见范围。这两个前提缺一不可不是单纯在流程图上画两个节点就行。3.2 配一个审批流从新增单类型到设置审核节点后台配置页一般分两层先建“单据类型”再配“审核流程”。单据类型定义这张单要填什么字段审核流程定义这些字段值由谁处理、在什么条件下跳转。先加一张请假单字段至少包含开始时间、结束时间、请假事由、请假天数。保存后系统会生成对应的单据 ID后续流程节点都挂在这个 ID 上。为了方便看清流程节点的本质下面用一段描述配置结果的代码来表达它是后台保存后内存里的逻辑结构不是让你直接覆盖进项目// 审批流节点结构后台配置后的效果示意 $flow [ title 请假申请, steps [ [ operator dept_manage, // 部门经理 action approve, // 审批 timeout 24 * 3600, // 24小时未处理 timeout_action auto_pass,// 自动审批通过 ], [ operator hr_manage, // HR经理 action approve, timeout 48 * 3600, timeout_action auto_remind, // 只提醒不自动处理 ], ], condition [ field leave_days, op , value 3, // 请假超过3天才走HR确认 ], ];这段结构的重点在于审批流不是一条直线而是带条件判断的。你在后台添加“请假超过 3 天需要 HR 确认”之类规则时系统背后就是在流程节点的 condition 里写了一个比较表达式。理解了这个模型你再去看后台那些“新增条件”“添加分支”按钮思路会清晰很多。3.3 验证审批流后台模拟提交和脚本检查待办配置完审批流不能只在界面看看要真实提交一张请假单用另一个测试账号登录查看待办。信呼的待办逻辑会按照 operator 字段去匹配当前用户角色如果角色不匹配单子会卡在“无处理人”上后台不报错但也走不下去。这一步我会用一个命令行小脚本去调待办查询接口确认数据从表单走到了待办表。假设包内有 cli.php 这类入口执行是这样的php cli.php test/get-todo --userid1001如果包内没有对应入口可以写个一次性 PHP 脚本加载入口文件后调用待办方法。脚本的目的不是刷日志而是完成闭环验证提交单子检查待办模拟审批最后查看状态。这一步走过去才说明流程节点真的被系统接收了而不是只在配置页面上显示好看。4. 信呼 v1.8.6 上线避坑5 个部署期必踩的坑与排查手段4.1 登录后白屏或 500PHP 扩展缺失和缓存叠加现象安装向导走完数据库导入成功输入管理员账号登录后页面空白Nginx 的 error.log 里出现Class PDO not found或者Undefined function mb_substr。原因PHP 版本环境换了但 pdo_mysql 和 mbstring 扩展没装。另一个叠加因素是 runtime 缓存里残留旧信息导致新代码没生效。解决先补扩展再检查缓存。sudo apt install php7.4-mysql php7.4-mbstring php7.4-curl php7.4-gd php -m | grep pdo_mysql重启 PHP-FPM 后清空 runtime 目录里生成的文件只保留目录本身。这两步做完白屏基本消除。如果还白就打开 PHP 的 display_errors 看真实报错不再盲目改权限。4.2 数据库导入失败或中文乱码字符集和排序规则打架现象执行mysql xinhu install.sql时报Unknown collation utf8mb4_0900_ai_ci或者导入成功但后台搜索中文查不到。原因SQL 文件来自 MySQL 8.0 导出带着 utf8mb4_0900_ai_ci 排序规则而目标库是 MySQL 5.7不认识这个规则。字符集不匹配则会在索引和比较时出现不一致。解决替换排序规则后继续导入。sed -i s/utf8mb4_0900_ai_ci/utf8mb4_unicode_ci/g install.sql mysql -uroot -p --default-character-setutf8mb4 xinhu install.sql这里要记住导入前先确认目标库版本不要等报错再排查。这个坑的隐蔽性在于导入失败是显性报错替换后数据看起来正常但中文搜索问题会在上线后爆发到时候你要排查的范围更大。4.3 打卡记录时间慢 8 小时PHP 时区没配置现象系统首页时间正常但考勤打卡记录显示的时间总比实际时间晚 8 小时排班逻辑也跟着错位。原因PHP 默认时区是 UTC数据库连接后写入的时间也是 UTC某些报表接口没有再做一次时区转换导致只有部分模块时间不准。解决把 PHP 时区和平台时区配置都改成 Asia/Shanghai。date.timezone Asia/Shanghai改完重启 PHP-FPM再清一次 runtime 缓存。现有历史数据如果已经写错只能做数据订正不影响后续打卡记录。上线前用测试账号打一次卡比上线后人工改数据省事得多。4.4 附件上传报错或提示 413上传限制在三个地方现象上传一份 20MB 的文件被拒页面上提示 413 Request Entity Large或者直接报“上传失败”但没任何原因。原因Nginx 的 client_max_body_size、PHP 的 upload_max_filesize、post_max_size 三个值不一致。Nginx 先拦截大请求PHP 再拦一次任何一个不够都会失败。解决三层一起调。client_max_body_size 50m;upload_max_filesize 50M post_max_size 50M重启 Nginx 和 PHP-FPM。然后检查 upload 目录对 PHP 运行用户是否可写chown -R www-data:www-data upload/ chmod -R 755 upload/我不建议给 777 权限。权限问题的正确解法是让运行用户拥有目录而不是让所有人都能写。777 在出问题时会让日志里看不出是谁写的安全上也很难收场。4.5 登录时长形同虚设会话生命周期和在线判定不一致现象外网用户登录 OA挂机不到半小时就被踢回登录页另一些账号挂一天也不会掉线安全策略完全失控。原因PHP 的 session.gc_maxlifetime 和 session.cookie_lifetime 不一致或者会话存放在 Redis/MemcachedGC 回收策略由服务端配置决定PHP 里的设置就不会生效。解决先把两组会话参数对齐。session.gc_maxlifetime 7200 session.cookie_lifetime 0cookie_lifetime 设为 0 表示浏览器关闭时失效这是最安全的做法。如果公司习惯常驻登录就把两个参数都设成 7200 秒再重启 PHP-FPM 做一次真实验证。登录时长这个问题留的越大账号暴露风险越高上线前就要按公司安全策略定下来。5. 调整登录时长与会话过期让 OA 的在线状态贴合公司习惯上一节讲的会话参数是基础真正把“登录时长”设置好还要分两层理解会话过期时间和前端心跳续期。很多人在后台只看到一个“有效时长”的输入框以为填个数字就完了实际上前端页面如果每 5 分钟自动发一个心跳请求那么会话会被无限续期后台填的 30 分钟形同虚设。反过来如果心跳机制关了用户正在编辑一封长邮件手一停就会掉线这也是问题。因此我建议按使用场景把登录时长拆成三档。场景session 过期时间前端心跳说明公司内网宽带8 小时5 分钟上班挂机不被频繁踢出外网/混合办公4 小时5 分钟平衡安全与便利访客或供应商账号本次会话关闭无心跳浏览器关闭即失效我一般会在后端配置里把这三个档位写成常量然后让后台页面的选择项去读常量而不是让运维人员直接在代码里改 session 配置。这样谁调整了登录时长改成多少都能够在系统日志里留下痕迹。登录时长的本质是一次安全策略选择你能容忍的便利程度决定了账号在暴露状态下能停留多久。最后说个我自己的教训。早前有个项目为了减少同事抱怨我把管理员账号的过期时间设成 12 小时又开着 5 分钟心跳。结果是某个离职员工的老账号在三个月后依然能登录后台被发现时差点出大问题。后来我强迫自己养成了一个习惯所有外部协作账号单独建角色会话过期时间强制 4 小时心跳关闭。这个做法沿用到现在至少没再出过类似事故。希望帮到你。本文还有配套的精品资源点击获取