信呼OA v1.8.6部署实战：PHP环境、工作流与微信审批避坑指南

简介信呼协同办公OA系统 v1.8.6是一套开源的PHP协同办公解决方案面向需要搭建内部工作平台的企业与开发者覆盖工作流审批、任务管理、日程安排、文件管理、即时通讯、公告通知、人事考勤等常用模块。它采用跨平台设计支持Android/iOS移动端、Windows/Mac客户端及Web浏览器访问移动办公场景下也能随时处理审批与待办适合远程办公或多终端协同。整个资源包共1248个文件以597个PHP业务代码为主体辅以HTML/JS/CSS前端页面、GIF/PNG图片素材及SQL数据库脚本压缩包仅2.79MB便于快速下载部署或二次开发。当前已有317人学习。通过这份源码可以直观了解OA系统从数据库设计到前后端交互的完整实现也能基于开源协议按企业流程定制审批、考勤等模块同时看清跨平台客户端与Web端的整合思路是学习PHP项目架构和企业级应用开发的实用参考。1. 信呼协同办公OA系统 v1.8.6轻量OA的务实选型信呼协同办公OA系统 v1.8.6 这个名字通常出现在两种场景里小公司IT在选型时被推荐“开源、便宜、能改”或者技术负责人带着“把审批从微信聊天记录里搬出来”的诉求开始搜。它解决的核心问题很朴素——请假、报销、用印、公文审批不再靠私聊和截图而是有一条带留痕、可追溯、能催办的流程。适合几十到两百人、没有预算买泛微这类商业OA、但愿意在运维上花点时间的团队。v1.8.6是1.8代的稳定修补版流程审批、考勤、客户管理、公告、日程这些OA系统最常用的模块都已覆盖。相比商业产品它不是开箱即用有些配置需要自己翻代码、翻php.ini这正是这篇文章要把你带进的方向从部署到跑通从移动端到避坑最后把系统接进自己的日常运维里。2. 先从装环境开始信呼 v1.8.6 对 PHP 和 MySQL 的真实要求2.1 PHP 版本比数据库版本更敏感装对运行环境省一半事v1.8.6 属于 PHP 5.x 时代的产物代码里大量使用当时主流的写法。我的建议是不要追新装一台 PHP 7.0 到 7.4 之间的环境最稳MySQL 用 5.6 或 5.7 都行MariaDB 10.2 以上问题也不大。如果直接把系统丢到 PHP 8 上大概率会出现页面白屏、类库加载失败、隐式类型转换报错这类兼容问题而这些报错往往只在特定页面触发排查起来特别消耗耐心。数据库版本为什么没那么敏感因为信呼对数据库的调用大多走的是pdo_mysql这套标准接口MySQL 5.5 以上基本都能跑。真正容易出问题的是字符集——安装时如果库的默认字符集不是utf8mb4后面录入中文姓名、表情符号、特殊符号时会出现乱码或插入失败。创建数据库时显式指定字符集比事后转换省事得多。另一个容易被忽略的环境项是 PHP 扩展。安装前先确认pdo_mysql、gd、fileinfo、openssl、curl这几个扩展都已开启。信呼的安装页自带环境检测这一步能拦下大部分问题但如果你用的是一个精简过的 PHP 镜像检测过不了再去装扩展反而要走弯路。2.2 在 Linux 服务器上用四步装起来目录、授权、库表、安装页拿到 v1.8.6 的源码包之后整个安装过程基本就是四个动作。先解压并放到 Web 根目录再创建数据库和专用账号然后用浏览器走安装向导最后处理安装目录的残留。# 假设你的Web根目录是 /data/www unzip xinhu_v1.8.6.zip -d /data/www/ mv /data/www/xinhu_v1.8.6 /data/www/xinhu chown -R www:www /data/www/xinhu chmod -R 755 /data/www/xinhu # 在 MySQL 里创建数据库字符集必须指定 CREATE DATABASE IF NOT EXISTS xinhu DEFAULT CHARSET utf8mb4; GRANT ALL PRIVILEGES ON xinhu.* TO xinhu_userlocalhost IDENTIFIED BY 你的密码; FLUSH PRIVILEGES;这里有三件事要说明白。第一chown -R www:www是关键一步PHP-FPM 进程以www用户运行如果目录属于 root安装时系统写不了配置文件页面会卡在权限提示上。第二数据库账号只授权了xinhu一个库这是有意为之避免安装后数据库账号权限过大万一 Web 被入侵不至于把整个 MySQL 拖下水。第三如果服务器上开了 SELinuxchmod -R 755仍然可能不够需要确认/data/www/xinhu的 SELinux 类型能允许 HTTP 服务写入实在搞不定就临时setenforce 0验证确认是 SELinux 导致再针对性放行。浏览器打开http://你的域名/install/安装向导会先检查环境和目录权限检查通过后填写数据库主机、库名、账号、密码和表前缀。表前缀默认xinhu_如果同一个库里要跑多套系统改前缀能隔离数据否则保持不变即可。接着设置管理员账号和密码这一步设置的账号就是整个 OA 系统的最高权限账号密码强度别糊弄。安装完成后系统会提示删除或改名install目录。这个操作不是洁癖是安全底线留着安装目录任何人都能重新执行安装流程把数据库配置改成自己的服务器等于把整套系统拱手让人。常见做法是mv install install.bak确认系统运行正常后再删除。2.3 装完先看这三个目录入口、配置、业务模块的位置一个典型的信呼解压目录长这样记下这几个位置后面所有排查和二次开发都跟它们相关。/data/www/xinhu ├── index.php # 前端入口文件 ├── install/ # 安装目录装完要改名或删除 ├── include/ # 核心类库和配置文件 ├── webmain/ # 业务模块代码按功能分目录 │ ├── flow/ # 工作流模块 │ ├── attendance/ # 考勤模块 │ ├── customer/ # 客户管理 │ └── ... ├── upload/ # 上传的附件和图片 └── backup/ # 数据库备份和计划任务脚本index.php是整个系统的单一入口所有请求都经它转发Nginx 下如果访问非首页路径变成 404多半是重写规则没配常见做法是加上 ThinkPHP 风格的伪静态规则把不存在的文件路径 rewrite 到index.php。include目录里存的是核心配置和数据库连接信息安装时填的库名和密码就落在这一层。webmain按业务模块分目录以后要改审批逻辑、调考勤算法主要就是在这个目录里找控制器文件而不是在include里乱翻。upload目录的权限要特别留意。员工上传附件、头像、审批单据全写在这里如果空间满了轻则附件传不上去重则整个系统响应变慢。上线第一天就加一个对upload目录的磁盘空间监控比出了问题再排查省心得多。3. 工作流是OA的命根子表单、审批节点与数据流转3.1 先理解表单和流程是两套东西再动手设计新手最容易犯的错是把表单和流程混成一件事。实际上信呼的工作流是把“填什么”和“怎么批”分开管理的表单定义字段和布局流程定义节点和路由。两者通过一个流程编号绑定表单数据落库流程状态跑在另一个表里。表单设计器里常见的字段类型大概这么几类字段类型在表单里的作用注意点输入框单行文本填事由、标题长度限制数字金额、天数、数量可用于条件判断日期时间请假起止、出差时间前后端格式统一下拉选项请假类型、费用类型选项值写稳定附件上传报销单据、合同扫描件存 upload 目录人员选择指定协同人、知会人支持多选审批人决定下一节点谁处理流程引擎专用字段这里面最特殊的是“审批人”字段。它不是一个普通的人名输入框而是流程引擎识别“谁来处理这条待办”的关键标记。常见做法是发起人在单据上选择自己的部门主管然后流程节点里取这个字段的值作为下一个审批人。如果把审批人做成普通下拉框员工自己填名字流程就失去了控制力。设计表单时的另一个原则是字段可复用。比如“请假类型”这种下拉选项应该在字典里统一维护而不是每个表单各写一份。信呼的字段模型里下拉选项通常绑定到系统的字典类型改了字典所有引用它的表单会同步生效。这样后续调整福利政策时不用重新部署表单。3.2 请假审批的流程配置条件分支、会签和转审的落法以最常见的请假流程为例在后台“工作流 - 流程设计”里把节点按这个顺序串起来开始节点部门主管审批条件节点判断请假天数超过三天进总经理审批三天以内直接抄送人事最后结束。条件分支的表达式并不复杂逻辑就是比较表单字段的值。比如请假天数days大于 3走总经理节点小于等于 3走抄送节点。这里的字段名必须是表单设计的字段标识不能在表达式里写字段中文名否则条件永远匹配不上。审批节点有两种模式需要提前和同事约定会签和或签。会签是这个节点所有人都审完才流转到下一步适合合同审批这类需要集体决策的场景或签是只要有一个人同意就继续走适合日常报销。信呼里每个审批节点可以独立设置模式如果上线后有人反馈“流程卡在某个领导那里”先确认这个节点是不是被配成了会签。3.3 一条审批记录从发起到归档数据是怎么走的把流程拆开看一条审批记录的生命周期是这样的发起人提交表单系统插入一条流程主记录和一条表单数据记录同时生成第一个节点的待办审批人打开待办填写意见提交同意或不同意系统写入审批日志再根据当前节点和条件表达式计算下一个节点生成新的待办直到没有后继节点流程结束归档。// 审批动作落库的示意逻辑 function submit_check($flowid, $record_id, $check_result, $memo) { // 1. 记录本次审批意见 $log [ flowid $flowid, record_id $record_id, checkuid $_SESSION[uid], checktime date(Y-m-d H:i:s), result $check_result, // 1同意 2不同意 3退回 memo $memo ]; insert(flow_log, $log); // 2. 根据result和节点条件计算下一个待办人 $next_node get_next_node($flowid, $record_id, $check_result); if ($next_node) { create_todo($next_node); } else { // 没有下一节点流程结束通知发起人 send_msg(审批流程已结束); } }这段示意逻辑里$check_result的三种取值是整个审批语义的核心同意、不同意、退回。三条路线的后续动作完全不同。同意是继续往后走不同意意味着流程终止发起人要重新发起或修改内容退回则是把单据打回给发起人修改后再重新提交流程从被打回的节点重新开始。这里有一个实际部署时容易吃亏的点上线前要和业务方约定清楚“不同意”和“退回”的使用习惯。很多公司把“不同意”理解为退回希望对方改完再传回来但系统里不同意是终止流程发起人只能重新填单之前的附件和流转记录全没了。我的血泪经验是第一条流程跑通前先组织一次五分钟的使用说明把这两个操作的区别讲明白。4. 把OA装进微信公众号接入、登录时长与移动审批的边界4.1 微信公众号回调配置AppID、Token 和签名校验的暗坑信呼的移动端体验最典型的落地方式是把系统接入微信公众号或企业微信自建应用员工在企业微信里接收审批待办点开就能处理。这件事的难点不在信呼这头而在微信公众平台那头的服务器配置。先在微信公众平台的开发者配置里填服务器 URL 和 Token。这个 URL 必须是外网可访问的域名不能用 IP端口必须被防火墙放行。填写后微信会发一个 GET 请求到你填的 URL带上signature、timestamp、nonce、echostr四个参数你的服务器要做一次校验校验通过把echostr原样返回微信才能确认这个 URL 是你的。// 微信回调验证的签名校验逻辑示意 $echostr $_GET[echostr]; $signature $_GET[signature]; $timestamp $_GET[timestamp]; $nonce $_GET[nonce]; $token 你在信呼后台填写的Token; $tmpArr [$token, $timestamp, $nonce]; sort($tmpArr, SORT_STRING); $tmpStr sha1(implode($tmpArr)); if ($tmpStr $signature) { echo $echostr; // 微信确认服务器可用 }这段代码看着简单sort($tmpArr, SORT_STRING)是绝大多数人翻车的地方。PHP 的sort()默认排序是数值比较三个字符串里有数字开头的值排序结果就乱了签名校验必定失败。必须显式指定SORT_STRING按字符串排序。这个签名校验的逻辑像个黑匣子一旦失败微信公众平台上的提示语非常模糊排查半天往往发现只是这一个参数的问题。验证通过后信呼后台还要填 AppID 和 AppSecret这两项用来换取全局的access_token。微信的access_token有效期 7200 秒每次调用接口都带同一个 token所以系统里必须有缓存层不要在每次请求时都重新获取。缓存时间建议设置为 7200 减 300 秒留出刷新余量避免边缘时间拿到失效 token。曾经有同事把缓存设成 7200 秒整结果每周都出现一两次消息推送偶发失败查了两天才发现是这个边界问题。4.2 登录时长设置和泛微这类商业OA不同信呼要调两处“OA系统登录时长设置”在很多管理员印象里是一个后台页面上的数字泛微这类商业 OA 在系统设置里就有“会话超时时间”的配置界面填个分钟数保存即可。信呼开源版没有这么显眼的选项登录时长由两层一起控制少改一处效果就对不上。第一层是 PHP 的 session 生命周期。PHP 默认的session.gc_maxlifetime是 1440 秒也就是 24 分钟超时后 session 文件可能被回收用户被强制退出。第二层是信呼自身维护的用户登录态它在 session 之外还会记录一个“最后活跃时间”长时间不操作就判定离线即使 session 文件还在。; php.ini 里相关的两个参数 session.gc_maxlifetime 7200 ; session 文件存活时间单位秒 session.cookie_lifetime 0 ; 0 表示关闭浏览器即失效改登录时长时两个值要联动设计。如果希望员工一天内不需要重复登录把session.gc_maxlifetime调到 8 小时同时把信呼应用层的在线超时阈值调到同样长度或更长。常见做法是在系统配置文件里增加一个auth_expire常量后台的“系统设置”里如果有在线时长选项就填那里没有就直接改这个常量。两边不一致的结果很诡异——用户明明在操作一到某个时间点就被弹回登录页。配置项位置建议值作用session.gc_maxlifetimephp.ini7200session 文件回收时间session.cookie_lifetimephp.ini0浏览器关闭失效auth_expire信呼配置文件7200应用层登录态超时这里想提醒一句登录时长不要无脑调到“永不失效”。OA 系统里的审批、考勤、工资数据敏感如果员工的电脑忘记锁屏系统一直保持登录状态相当于给所有路过的人敞开了门。我一般建议 4 到 8 小时之间并且配合公司的离职注销流程员工离职当天清掉账号的登录态。4.3 信呼与商业平台在移动协同上的实际差距泛微这类商业 OA 的移动端优势主要体现在三块组织权限模型成熟子管理员能精确控制到功能级按钮移动 App 体感流畅推送到打开详情几乎无感知延迟低代码表单能力强业务人员也能自己拖出复杂表单。信呼的差距是客观存在的。它的移动端更多是“能用”而不是“好用”企业微信里的审批页面简洁、加载快但复杂的联动表单、批量审批、跨系统数据回写都做不了。这个差距在接受范围之内取决于团队的需求层次——如果只是请假、报销、用印这些标准流程信呼的移动协同完全够用如果要搞复杂的报价审批、预算控制花在信呼上二次开发的成本可能比直接上商业平台更高。5. 避坑信呼 v1.8.6 跑起来之后我踩过的环境与应用坑5.1 PHP 升级后页面白屏先看 error_log 再决定改代码还是换环境现象系统原本跑在 PHP 5.6 上正常运维顺手升级到 PHP 7.4 或 8.0打开首页白屏浏览器控制台只有 500 或一个空白响应。原因v1.8.6 时代的老代码与 PHP 新版本的兼容性问题常见的有构造函数命名方式变化、隐式类型转换被禁止、魔术引号相关逻辑失效。这些问题在代码里分散在各处不是改一行就能解决的。解决先看 PHP-FPM 的error_log定位第一条致命错误。如果报错集中在两三个文件可以直接改代码兼容如果报错成片出现最务实的做法是把 PHP 版本降回 7.0 到 7.4 之间把精力留到业务流程上。别和框架层兼容性较劲OA 系统是业务工具不是练手项目。5.2 安装时填对数据库信息仍连不上localhost 和 127.0.0.1 的差异现象安装向导环境检测全绿数据库名、账号、密码都确认无误下一步还是报“数据库连接失败”。原因PHP 连接 MySQL 时localhost和127.0.0.1走的是两种完全不同的协议。localhost默认走 Unix Socket127.0.0.1走 TCP。MySQL 账号授权时写的xinhu_userlocalhost跟 TCP 连接来自127.0.0.1的安全域不匹配。解决安装时数据库主机如果填localhost报错改成127.0.0.1再试反向也一样。或者直接用命令行先验证mysql -u xinhu_user -p -h 127.0.0.1能进说明账号没问题再用同样的主机名填安装页。5.3 微信端迟迟收不到审批推送回调URL和OpenSSL扩展的翻车点现象信呼后台微信公众号配置保存成功测试连接也没报错但员工在企业微信或公众号里收不到任何待办提醒。原因这类问题十有八九不是信呼的问题是回调链路没走通。服务器上的防火墙只放行了 80 端口但微信服务器要求合法域名必须走 443或者 PHP 的openssl扩展没装file_get_contents访问微信 API 的 HTTPS 地址时直接失败。解决先手动测签名校验接口curl https://你的域名/回调路径?echostrtest看有没有响应。再确认 PHP 里openssl扩展已启用命令行执行php -m | grep openssl检查。最后到微信公众平台重新保存一次服务器配置如果保存成功说明签名链路已通保存失败按SORT_STRING那段逻辑再查一遍代码。5.4 流程审批人总是不对组织架构的上级关系要先理顺现象请假流程里配的是“发起人的直属上级审批”结果部门经理和总经理都收到了待办或者一个人都没收到。原因流程引擎取“直属上级”依赖组织架构里的层级关系如果员工基本信息里没有维护“上级”这个字段或者一个人同时挂在两个部门系统取到的是第一条匹配记录自然就错乱了。解决别急着改流程定义先回人员管理里把所有人的“上级”字段过一遍。尤其是兼职、借调、历史遗留账号这些人的组织关系理清了流程节点才会听话。上线工作流模块之前花半天时间理顺组织架构是整个上线计划里性价比最高的一步。5.5 考勤打卡时间差8小时PHP 和 MySQL 的时区要一起改现象员工用手机打卡考勤记录里的时间比北京时间慢了 8 小时但服务器执行date显示的时间是对的。原因PHP 默认时区如果没设置取的是UTCMySQL 的time_zone如果也是系统默认写入DATETIME字段时会做一次转换。PHP 和 MySQL 各自转一次时间就偏了 8 小时。解决php.ini里设置date.timezone Asia/ShanghaiMySQL 里执行set global time_zone 08:00两个时区对齐后在系统里重新打一次测试卡验证。这个坑的隐蔽之处在于考勤之外的流程记录用的是相对时间看不出异常只有打卡这种绝对时间才会暴露。6. 更进一步把信呼接进定时任务和外部系统6.1 用系统已有登录态做一个外部查询页信呼的用户体系和登录态是现成的完全可以基于它做一个内部小工具让员工在 OA 之外快速查询自己的审批进度、考勤汇总、加班时长而不用重新造一套权限。常见做法是写一个独立的 PHP 入口放在信呼的webmain目录下开头复用当前用户会话的判断逻辑。员工登录 OA 后浏览器在同一域名下访问这个页面直接读取 OA 的 session识别当前用户再查流程记录表按登录人的员工 ID 过滤数据展示出来。如果要做成更正式的接口可以包装成 JSON 输出给企业微信里的 H5 应用调用效果等同于一次轻量二次开发。// 复用OA登录态的查询页示意 require_once ../include/api.php; $login_uid get_login_uid(); // 获取当前登录用户ID $rows query(SELECT name, addtime, states FROM flows WHERE uid $login_uid ORDER BY addtime DESC LIMIT 20 ); foreach ($rows as $row) { echo $row[name] . - . $row[addtime] . - . $row[states] . \n; }这个方案的边界是外部系统要访问信呼的数据不推荐直接操作数据库最好走信呼提供的 API。两个系统之间传数据用接口而不是共用数据库表耦合度低后续信呼升级或者二次修改不会互相牵制。6.2 定时任务考勤导出和审批催办的自动化写法OA 系统里有两类重复劳动最适合交给定时任务一类是周期性的数据导出比如每天早上把昨天的考勤异常记录汇总给人事另一类是催办比如某个审批待办超过 40 小时没人处理自动给审批人的上级发通知。信呼后台本身有计划任务的管理界面可以在系统里配置周期执行如果信呼跑在独立的服务器上直接用系统 crontab 也完全可行两种方式选一种即可不用重复配置。# 每天早上8点导出昨天的考勤汇总 0 8 * * * /usr/bin/php /data/www/xinhu/backup/export_attendance.php /dev/null 21 # 每10分钟扫描一次待办超过40小时未处理的通知督办人 */10 * * * * /usr/bin/php /data/www/xinhu/backup/press_pending.php /data/logs/oa_cron.log 21这两条 crontab 里第一条的输出写到/dev/null因为导出脚本如果成功会生成 CSV 文件脚本自身的输出没有意义第二条的输出写到日志文件因为催办脚本可能需要人工排查漏发和错发。写完 cron 后先手动跑一次脚本确认没有 fatal error再观察一两天日志。我给一家公司上线信呼后考勤统计一直不准查到最后是脚本在 SQL 里直接拼了服务器日期而服务器时区没设——现在我的习惯是上线前先把时区、扩展、目录权限整个检查一遍再让脚本跑起来。这段路走完这套轻量 OA 才算是真正接进了公司的日常运转里。希望帮到你。本文还有配套的精品资源点击获取