简介信呼开源办公OA系统设计源码包面向需要快速搭建企业内部办公自动化平台的中小企业、开发者及运维人员基于PHP与HTML、JavaScript、CSS构建支持APP、PC客户端、REIM即时通信和服务端多端接入。压缩包共1460个文件其中733个PHP文件负责核心业务逻辑与数据交互178个JavaScript文件与190个HTML文件实现动态界面与页面结构231个GIF、90个PNG等图像资源丰富视觉表现另有19个CSS样式表、SQL数据库脚本、字体文件和说明文档整体仅7.21MB按include、js等目录清晰划分便于定位与二次开发。已有1020人学习下载。系统涵盖任务管理、日程安排、文档共享、权限控制等常用办公模块结合APP和PC客户端等多端接入方式可帮助读者深入理解开源OA系统的目录组织、前后端协作模式与多端口部署思路适合作为PHP项目实战参考或企业信息化改造的基础框架。1. 基于PHP的开源办公OA系统设计源码先搞清楚它值不值得你花时间公司里上一套商业OA报价往往按人头算几十人的小团队一年也要花掉不少预算后面加个模块还要再谈一期项目于是不少人把目光转向基于PHP的开源办公OA系统设计源码。这类开源OA通常自带组织架构、审批流、公告日程、考勤报表这些基础能力技术栈只有PHPMySQL部署成本低改起来也不受厂商限制。它适合两类人一类是想自己掌控系统的中小IT负责人另一类是拿整套业务源码学设计的开发者。落地的标准路径是先把目录结构和鉴权流程梳理清楚再部署到LNMP环境完成数据库初始化和应用配置然后按公司的审批、考勤规则做二次开发。下面按这条路径走一遍把读源码、部署和踩坑的细节尽量说透。2. 拆解PHP OA的源码结构从登录鉴权到审批流的底层设计拿到源码先别急着往服务器上扔。我一般会先花半天时间读三样东西安装向导、全局配置文件、建表SQL。这三个文件能看出源码的完整度和维护水平。很多课程设计级别的源码界面做得像模像样但数据库表设计一塌糊涂流程状态用中文字符串存审批记录没有独立日志表这种源码就算能跑起来二次开发也会让你痛不欲生。读结构这件事本质是为了确认这套基于PHP的开源办公OA系统设计源码的扩展边界哪些业务逻辑可以靠配置解决哪些必须改代码哪些改了会牵连其他模块。2.1 为什么PHP仍是开源OA的主流选型生态、成本与可维护性OA这类系统的本质是“表单 状态流转 权限控制”页面多、逻辑重但在计算上不复杂天然适合PHP这种请求即用即走的运行模型。过去泛微、致远、蓝凌等商业产品已经把审批流、门户、考勤这套模式教育了市场开源PHP OA要做的就是把同样的事做出来但去掉授权成本。选PHP而不是Java最现实的原因有三条一是部署门槛低一台云主机加MySQL就能跑不需要中间件和JDK调优二是二次开发成本低改完PHP脚本重启PHP-FPM就生效不像Java要重新打包发布三是人才池大能写PHP的人远比能改商业OA二开的顾问好找。对比维度放在这里方便你在选型汇报时直接抄对比维度PHP开源OAJava开源OA商业SaaS OA部署资源单台云主机MySQL需要JDK/中间件内存要求高开箱即用按年付费二次开发成本改脚本重启FPM生效编译打包发布链路长受平台API约束人员门槛能找到PHP开发即可需要成建制Java团队不写代码靠配置数据可控性数据库在自己手里数据库在自己手里数据在厂商侧长期维护靠社区和自主维护靠社区和自主维护续费才有服务这套对比只说明一件事预算有限、流程灵活、团队里有人愿意碰代码的场景PHP开源OA是性价比最稳的起点。它的问题是安全性、并发上限和移动端体验要靠自己补这也是后面章节要重点讲的坑。2.2 先读四个目录入口、控制器、模型与模板老一代PHP OA的目录结构大同小异核心是四个部分public入口、app控制器、model数据模型、view模板。入口文件是整个请求的唯一通道所有访问都先经过它再做路由分发。下面这段代码是这类源码里最常见的写法?php // index.php 统一入口所有请求先经过这里再做路由分发 require __DIR__ . /../config/config.php; // 加载数据库、鉴权等全局配置 require __DIR__ . /../system/Loader.php; // 类自动加载器按命名空间找控制器和模型 $uri trim($_SERVER[REQUEST_URI] ?? , /); $route parse_url($uri, PHP_URL_PATH) ?: home/index; list($controllerName, $actionName) array_pad(explode(/, $route, 2), 2, index); $controllerClass \\app\\controller\\ . ucfirst($controllerName); if (!class_exists($controllerClass)) { http_response_code(404); exit(route not found); } $controller new $controllerClass(); $controller-$actionName();这段入口代码的逻辑并不复杂先加载配置和自动加载器然后从请求URI里拆出控制器名和方法名最后实例化控制器并调用对应方法。注意两个参数细节array_pad(explode(/, $route, 2), 2, index)处理的是“没有方法名”的情况比如访问/login会默认调到login控制器的index方法$controllerClass前面的反斜杠是根命名空间防止在子命名空间里拼错路径。读懂这段你就知道为什么二开时新增一个功能要从控制器写起也明白为什么有些人直接把PHP文件扔到public目录里能访问但路由规则全乱了。控制器里的写法通常是把业务结果放进数组或对象最后由接口层统一json_encode输出。这就是常说的“PHP接口数组对象”风格。好处是前端拿到的响应结构稳定调试网络请求时一眼能看出是业务报错还是框架报错。我在评估一套源码时会重点看控制器的厚薄控制器太厚说明业务逻辑全堆在表现层控制器薄、模型层厚才是能长期维护的结构。2.3 登录鉴权与审批流状态机读懂核心表字段就算入门OA的命根子是两张表用户表和流程表。用户表决定谁能进系统流程表决定事怎么流转、记录怎么留痕。下面这张表是大多数PHP开源OA的核心表设计字段名有差异但骨架基本一致表名关键字段作用sys_userid, username, password_hash, dept_id用户表密码字段必须是hash不能明文sys_deptid, parent_id, name组织架构树靠parent_id形成层级workflowid, title, form_type, status流程实例主表status存当前状态workflow_nodeid, workflow_id, node_name, approver_id, status流程节点记录每一步的审批人和节点状态workflow_logid, workflow_id, action, user_id, created_at审批轨迹只追加不修改其中的状态字段成熟源码一般用tinyint整数存枚举值比如0未提交、1审批中、2已通过、3已驳回。用整数而不是中文字符串是为了排序、统计和并发更新时不产生歧义。判断一套源码是不是课程设计水平看这一个字段就够。排查流程问题时下面这条SQL是基本功它能把“当前用户的待办”和“流程卡在哪一层”一次查清楚-- 查看当前用户的审批待办判断流程卡在哪一层 SELECT w.id, w.title, n.node_name, n.approver_id FROM workflow w JOIN workflow_node n ON n.workflow_id w.id AND n.status 1 WHERE n.approver_id 当前用户ID;这条SQL的核心是n.status 1它筛出的是“当前正在等待审批”的节点。如果上一节点审批通过后下一节点的待办没出现多半是这里关联的approver_id没写对或者workflow_node里根本没有生成下一节点记录。把这条SQL跑一遍是后续所有流程排查的第一步。3. 把PHP开源OA部署到LNMP环境环境配置、数据库初始化与站点上线部署这件事对老手来说是半小时的机械操作对新手来说是第一个大坎。因为这套源码多半不是最新框架写的可能用的是老式mysql_connect或一批已废弃的PHP函数直接用PHP 8.x跑会直接Fatal error。所以环境版本的选择比命令本身更重要。3.1 LNMP环境搭建与PHP扩展老源码优先用PHP 7.4接触过大量二手OA源码后我养成了“先看语法再定版本”的习惯。大多数老源码基于PHP 5.6或7.0的语法写成PHP 8.0开始移除了一批函数、收紧了类型转换直接升级会冒出一堆致命错误。动手之前先用php -l对入口文件做语法检查再决定版本。保守做法是先跑PHP 7.4稳定之后再做8.x迁移评估。在Ubuntu 20.04上安装PHP 7.4及常用扩展add-apt-repository ppa:ondrej/php apt update apt install -y php7.4-fpm php7.4-mysql php7.4-mbstring \ php7.4-xml php7.4-gd php7.4-zip php7.4-bcmath systemctl enable --now php7.4-fpm这里的扩展不是随便装的php7.4-mysqlnd是连接MySQL的驱动老代码里mysqli和PDO都依赖它php7.4-mbstring管中文编码没有它mb_substr这类函数会直接报未定义php7.4-xml提供simplexml和DOMDocumentOA的XML导入、报表导出都靠它php7.4-gd是验证码图片和附件缩略图的基础。如果源码里用了Redis缓存还得加上php7.4-redis否则session入库配置不生效。装完扩展后php.ini里这几个参数必须调否则第一次传附件就会踩坑upload_max_filesize 20M post_max_size 24M max_execution_time 120 memory_limit 256M date.timezone Asia/Shanghaipost_max_size要比upload_max_filesize大因为附件只是POST请求的一部分请求头和其他表单字段也占体积memory_limit给到256M是为了跑报表统计、Excel导出这类吃内存的操作时区不设置的话日志时间戳和业务时间会差8小时排查问题会怀疑人生。改完参数记得systemctl restart php7.4-fpm。3.2 数据库初始化与应用配置从导入SQL到改好config源码包里的install/oa.sql是整套数据库的建表脚本手工一句句执行不是不行但容易漏掉表之间的依赖关系。正确做法是先用命令行建库再整库导入mysql -uroot -p -e CREATE DATABASE oa_system DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; mysql -uroot -p oa_system install/oa.sql字符集这里有个细节老源码默认建库是utf8也就是utf8mb3存生僻字和某些特殊符号时会报“Incorrect string value”错误。我的习惯是建库时直接用utf8mb4但前提是建表SQL里没有写死DEFAULT CHARSETutf8否则导入会按表自己的定义覆盖。导入完成后用SHOW TABLES;看一眼表数量是否和源码文档一致再用SELECT COUNT(*) FROM sys_user;确认基础数据在。接下来改应用配置。老式PHP OA的配置文件常是config/config.php内容是全局数组或一堆define。核心配置块长这样?php // config/config.php 按源码实际位置调整 return [ db [ host 127.0.0.1, port 3306, database oa_system, username oa_user, password 换成强密码, charset utf8mb4, ], session [ name OASESSID, expire 7200, ], upload [ max_size 20971520, // 20MB allowed_ext [jpg, png, pdf, doc, docx, xls, xlsx, zip], ], ];如果源码用的是老式define写法改动的本质是一样的数据库账号密码、session有效期、上传目录和大小限制。需要特别注意数据库连接不要用root账号单独建一个只拥有oa_system库权限的账号这是一道最简单的安全边界。改完配置后访问安装向导或首页能出现登录页说明PHP和MySQL之间的链路通了。提示部分源码安装向导会自动生成管理员账号初始密码写在README里。这种密码上线前必须改尤其是泛微E10这类商业OA曾因初始密码问题被扫过开源OA同样适用这个原则。3.3 Nginx站点配置与伪静态规则让URL不带index.phpPHP内置的php -S只适合本地开发生产环境还是用NginxFPM。站点配置里最核心的是try_files伪静态规则它把/index.php从URL里藏掉同时保证路由能正常分发server { listen 80; root /var/www/oa/public; index index.php index.html; location / { try_files $uri $uri/ /index.php$is_args$args; } location ~ \.php$ { fastcgi_pass unix:/run/php/php7.4-fpm.sock; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; } location ^~ /uploads/ { location ~ \.php$ { deny all; } } }try_files $uri $uri/ /index.php$is_args$args的意思是先找磁盘上的真实文件找不到就把请求转给入口文件由PHP路由解析。fastcgi_pass用的是Unix socket而不是TCP性能更好、少一层网络开销生产环境推荐这种方式。最下面那个/uploads/区块是安全配置它的作用是即使攻击者把PHP文件传到了上传目录Nginx层也直接拒绝执行。这行配置是后来补上的早期做OA部署时没人提这个结果吃过大亏。4. 上线前避坑清单PHP安全与OA二次开发的五个排查点部署完能登录只是开始。真正折磨人的是上线后的安全扫描和流程异常。这一章列五个高频问题每条都是按“现象、原因、解决”来写的基本都是血泪经验换来的。4.1 文件上传与PHP伪协议为什么源码自带的上传接口不能直接裸奔现象测试环境上传图片一切正常上线后过了几天服务器上多了一堆来路不明的PHP脚本。检查访问日志发现有人通过附件接口直接上传了可执行脚本。原因这类OA源码为了易用上传校验只查了后缀名黑名单比如把php拦住了但没拦住php3、phtml或者把文件存到/uploads/后这个目录里PHP解析仍然生效。另一个常见隐患是php.ini里开了allow_url_include配合源码里某些文件包含点就成了PHP伪协议利用链。解决上传校验改成白名单加随机文件名同时保证附件目录里任何PHP文件都不被执行。文件名校验用代码实现?php $ext strtolower(pathinfo($_FILES[file][name], PATHINFO_EXTENSION)); $allowed [jpg, png, pdf, doc, docx, xls, xlsx, zip]; // 白名单 if (!in_array($ext, $allowed, true)) { exit(file type not allowed); } $newName date(Ymd) . / . bin2hex(random_bytes(16)) . . . $ext;bin2hex(random_bytes(16))生成32位随机文件名彻底断掉攻击者“猜路径”的念想白名单比黑名单可靠得多黑名单永远有漏网之鱼。Nginx层再补上3.3里那个deny all配置上传漏洞就被封死了。4.2 XML导入与XXE风险OA里不起眼的导入接口也要管现象安全扫描时发现某个“从XML导入报表”的接口存在外部实体解析风险。原因是老代码解析XML时直接用了simplexml_load_string没有做任何实体限制。原因OA里经常有“外部系统数据导入”“第三方报表解析”这类冷门功能后台权限看着严但如果权限没覆盖到XML里带的DOCTYPE定义会在解析时被展开读取本地文件内容并带到响应里。广联达OA这类产品曾曝出过类似的XXE漏洞开源PHP OA如果复用了老式解析函数风险一模一样。解决解析XML之前显式禁止外部实体加载?php libxml_disable_entity_loader(true); $xml simplexml_load_string($rawXml, SimpleXMLElement, LIBXML_NONET);第一个参数是总开关禁用外部实体加载LIBXML_NONET阻断网络请求双保险。需要注意的是PHP 8.0之后libxml_disable_entity_loader被标记为废弃那时要改用libxml_set_external_entity_loader传一个返回空集的回调函数。老源码跑在7.4上前者够用但代码注释里要留个升级提醒。4.3 登录态失效与多端互踢Session设计没看懂的代价现象用户每隔十几分钟就被踢出登录或者在两个浏览器标签页里开着同一个OA一个标签保存操作另一个标签立刻失效。原因OA这种系统对会话要求高用户填半天表单一提交就掉线问题基本出在Session配置上。要么session.gc_maxlifetime太短PHP回收机制把还在使用的会话清掉了要么源码里的单点登录做得很粗暴每次登录都生成一个新的session_id把旧会话覆盖掉导致同一账号多端使用互相顶号。解决Session生命周期要按业务场景设置不能图省事用默认值同时把Session存到Redis里避免多台机器部署时会话不同步?php ini_set(session.gc_maxlifetime, 7200); ini_set(session.save_handler, redis); ini_set(session.save_path, tcp://127.0.0.1:6379);这里有两个参数要配套看session.gc_maxlifetime控制过期时间session.save_path指向Redis地址。多端互踢的问题根源在于同一用户的多个会话共用了一个session key要彻底解决需要把“用户在线会话表”单独建出来一个用户允许同时存在多个会话记录但后续请求要按会话id而不是按用户id取权限。这是老源码最常缺的一块表。4.4 审批流卡单状态字段不一致导致待办消失现象上一节点审批通过了下一节点的待办列表里没有数据。看数据库workflow表的status已经是2但workflow_node表的下一节点status还是0。流程明明“已通过”后续节点就是没人收到待办。原因源码里“更新流程状态”和“生成下一节点待办”是两条独立的SQL中间没有事务包裹。一旦第一步执行成功、第二步执行失败状态就永久错位。另一个常见原因是状态字段用了中文字符串或备注文本代码里判断值写错了比如存的是“已通过”代码却查“pass”。解决流程状态必须用整数枚举并且把“更新当前节点 生成下一节点待办”放进同一个数据库事务?php $pdo-beginTransaction(); try { $pdo-exec(UPDATE workflow_node SET status 2 WHERE id {$currentNodeId}); $pdo-exec(INSERT INTO workflow_todo (node_id, user_id) VALUES ({$nextNodeId}, {$approverId})); $pdo-commit(); } catch (Exception $e) { $pdo-rollBack(); error_log($e-getMessage(), 3, /var/log/oa_error.log); }事务的意义在于要么两步全部成功要么全部回滚不会出现“中间态”卡死。改造时把日志写进独立的错误文件排查问题时直接看日志比猜代码快得多。4.5 管理员密码丢了不要删库跑路现象部署的人离职了唯一的管理员账号密码没人知道再进不去后台。数据库里的密码是hash不可逆网上搜“忘记密码”也没搜到现成方案。原因老源码安装后没有预留自服务改密入口数据库里也没有备用管理员账号。这时候千万别急着删库重装那意味着所有流程数据和审批记录全部归零这个后悔药找不回。解决写一段CLI脚本直接生成新的密码hash并更新用户表?php $pdo new PDO(mysql:host127.0.0.1;dbnameoa_system, root, 你的数据库密码); $newPassword password_hash($argv[1] ?? Admin123456, PASSWORD_BCRYPT); $stmt $pdo-prepare(UPDATE sys_user SET password ? WHERE id 1); $stmt-execute([$newPassword]); echo password updated, new hash: {$newPassword}\n;$argv[1]是命令行传入的新密码没传就用默认值兜底跑完立刻修改。这个脚本上线前就要准备好放在运维目录里因为谁都有记错密码的时候。5. 把OA改顺手Excel批量导入、API鉴权与二次开发验证5.1 用Excel批量导入组织架构事务、幂等与字符集三个要点新公司入职一批人手动在后台一个个建账号效率太低。常见做法是把组织架构数据整理成CSV用一段一次性PHP脚本批量导入。CSV比xlsx省事不需要额外装PHPExcel扩展?php $pdo new PDO(mysql:host127.0.0.1;dbnameoa_system, root, ); $rows array_map(str_getcsv, file(users.csv)); $stmt $pdo-prepare(INSERT INTO sys_user (name, mobile, dept_id) VALUES (?,?,?) ON DUPLICATE KEY UPDATE dept_id VALUES(dept_id)); $pdo-beginTransaction(); foreach ($rows as $row) { if (empty($row[0]) || $row[0] 姓名) continue; // 跳过表头 $stmt-execute([trim($row[0]), trim($row[1]), (int)$row[2]]); } $pdo-commit();这段脚本里ON DUPLICATE KEY UPDATE是幂等关键它依赖表里mobile字段的唯一索引重复导入不会生成重复账号只是把部门信息刷新一遍。跳过表头用$row[0] 姓名判断简单直接。字符集方面CSV文件要用UTF-8编码保存用Excel另存为CSV时默认可能是GBK导入前用iconv(GBK, UTF-8, ...)转一下。5.2 给旧版OA的API加一层简单的token签名校验外部系统要调OA的组织架构接口旧源码的接口是裸的知道URL就能访问。最小改动方案是加一层签名校验脚本侧根据token验证请求是否合法?php function api_check() { $token $_GET[token] ?? ; $ts (int)($_GET[ts] ?? 0); $appid oa_api; // 调用方标识 $secret 换成随机长字符串; // 与调用方约定不落库 if (abs(time() - $ts) 300) exit(expired); $sign md5($secret . $ts . $appid); if ($sign ! $token) exit(invalid sign); }逻辑是时间戳ts加密钥拼成字符串再md5服务端算一次对比请求里的token。有效期300秒防止截获后长期重放密钥永远不出现在请求里。这个方法适合内部系统之间的轻量对接如果要对外开放给多个第三方再升级成OAuth体系。我前几年接手一套老PHP OA时一上来就急着改考勤逻辑结果没先验证环境与权限边界上线当周把一个旧接口的密码写死在了代码里回滚折腾了一整晚。之后养成的习惯是先跑通最小部署和安全基线再动业务代码每一次改动都要能用一段可重复的脚本或一次完整审批流程来验收。希望帮到你。本文还有配套的精品资源点击获取 PHP开源OA系统源码解析：从LNMP部署到二次开发避坑指南
简介信呼开源办公OA系统设计源码包面向需要快速搭建企业内部办公自动化平台的中小企业、开发者及运维人员基于PHP与HTML、JavaScript、CSS构建支持APP、PC客户端、REIM即时通信和服务端多端接入。压缩包共1460个文件其中733个PHP文件负责核心业务逻辑与数据交互178个JavaScript文件与190个HTML文件实现动态界面与页面结构231个GIF、90个PNG等图像资源丰富视觉表现另有19个CSS样式表、SQL数据库脚本、字体文件和说明文档整体仅7.21MB按include、js等目录清晰划分便于定位与二次开发。已有1020人学习下载。系统涵盖任务管理、日程安排、文档共享、权限控制等常用办公模块结合APP和PC客户端等多端接入方式可帮助读者深入理解开源OA系统的目录组织、前后端协作模式与多端口部署思路适合作为PHP项目实战参考或企业信息化改造的基础框架。1. 基于PHP的开源办公OA系统设计源码先搞清楚它值不值得你花时间公司里上一套商业OA报价往往按人头算几十人的小团队一年也要花掉不少预算后面加个模块还要再谈一期项目于是不少人把目光转向基于PHP的开源办公OA系统设计源码。这类开源OA通常自带组织架构、审批流、公告日程、考勤报表这些基础能力技术栈只有PHPMySQL部署成本低改起来也不受厂商限制。它适合两类人一类是想自己掌控系统的中小IT负责人另一类是拿整套业务源码学设计的开发者。落地的标准路径是先把目录结构和鉴权流程梳理清楚再部署到LNMP环境完成数据库初始化和应用配置然后按公司的审批、考勤规则做二次开发。下面按这条路径走一遍把读源码、部署和踩坑的细节尽量说透。2. 拆解PHP OA的源码结构从登录鉴权到审批流的底层设计拿到源码先别急着往服务器上扔。我一般会先花半天时间读三样东西安装向导、全局配置文件、建表SQL。这三个文件能看出源码的完整度和维护水平。很多课程设计级别的源码界面做得像模像样但数据库表设计一塌糊涂流程状态用中文字符串存审批记录没有独立日志表这种源码就算能跑起来二次开发也会让你痛不欲生。读结构这件事本质是为了确认这套基于PHP的开源办公OA系统设计源码的扩展边界哪些业务逻辑可以靠配置解决哪些必须改代码哪些改了会牵连其他模块。2.1 为什么PHP仍是开源OA的主流选型生态、成本与可维护性OA这类系统的本质是“表单 状态流转 权限控制”页面多、逻辑重但在计算上不复杂天然适合PHP这种请求即用即走的运行模型。过去泛微、致远、蓝凌等商业产品已经把审批流、门户、考勤这套模式教育了市场开源PHP OA要做的就是把同样的事做出来但去掉授权成本。选PHP而不是Java最现实的原因有三条一是部署门槛低一台云主机加MySQL就能跑不需要中间件和JDK调优二是二次开发成本低改完PHP脚本重启PHP-FPM就生效不像Java要重新打包发布三是人才池大能写PHP的人远比能改商业OA二开的顾问好找。对比维度放在这里方便你在选型汇报时直接抄对比维度PHP开源OAJava开源OA商业SaaS OA部署资源单台云主机MySQL需要JDK/中间件内存要求高开箱即用按年付费二次开发成本改脚本重启FPM生效编译打包发布链路长受平台API约束人员门槛能找到PHP开发即可需要成建制Java团队不写代码靠配置数据可控性数据库在自己手里数据库在自己手里数据在厂商侧长期维护靠社区和自主维护靠社区和自主维护续费才有服务这套对比只说明一件事预算有限、流程灵活、团队里有人愿意碰代码的场景PHP开源OA是性价比最稳的起点。它的问题是安全性、并发上限和移动端体验要靠自己补这也是后面章节要重点讲的坑。2.2 先读四个目录入口、控制器、模型与模板老一代PHP OA的目录结构大同小异核心是四个部分public入口、app控制器、model数据模型、view模板。入口文件是整个请求的唯一通道所有访问都先经过它再做路由分发。下面这段代码是这类源码里最常见的写法?php // index.php 统一入口所有请求先经过这里再做路由分发 require __DIR__ . /../config/config.php; // 加载数据库、鉴权等全局配置 require __DIR__ . /../system/Loader.php; // 类自动加载器按命名空间找控制器和模型 $uri trim($_SERVER[REQUEST_URI] ?? , /); $route parse_url($uri, PHP_URL_PATH) ?: home/index; list($controllerName, $actionName) array_pad(explode(/, $route, 2), 2, index); $controllerClass \\app\\controller\\ . ucfirst($controllerName); if (!class_exists($controllerClass)) { http_response_code(404); exit(route not found); } $controller new $controllerClass(); $controller-$actionName();这段入口代码的逻辑并不复杂先加载配置和自动加载器然后从请求URI里拆出控制器名和方法名最后实例化控制器并调用对应方法。注意两个参数细节array_pad(explode(/, $route, 2), 2, index)处理的是“没有方法名”的情况比如访问/login会默认调到login控制器的index方法$controllerClass前面的反斜杠是根命名空间防止在子命名空间里拼错路径。读懂这段你就知道为什么二开时新增一个功能要从控制器写起也明白为什么有些人直接把PHP文件扔到public目录里能访问但路由规则全乱了。控制器里的写法通常是把业务结果放进数组或对象最后由接口层统一json_encode输出。这就是常说的“PHP接口数组对象”风格。好处是前端拿到的响应结构稳定调试网络请求时一眼能看出是业务报错还是框架报错。我在评估一套源码时会重点看控制器的厚薄控制器太厚说明业务逻辑全堆在表现层控制器薄、模型层厚才是能长期维护的结构。2.3 登录鉴权与审批流状态机读懂核心表字段就算入门OA的命根子是两张表用户表和流程表。用户表决定谁能进系统流程表决定事怎么流转、记录怎么留痕。下面这张表是大多数PHP开源OA的核心表设计字段名有差异但骨架基本一致表名关键字段作用sys_userid, username, password_hash, dept_id用户表密码字段必须是hash不能明文sys_deptid, parent_id, name组织架构树靠parent_id形成层级workflowid, title, form_type, status流程实例主表status存当前状态workflow_nodeid, workflow_id, node_name, approver_id, status流程节点记录每一步的审批人和节点状态workflow_logid, workflow_id, action, user_id, created_at审批轨迹只追加不修改其中的状态字段成熟源码一般用tinyint整数存枚举值比如0未提交、1审批中、2已通过、3已驳回。用整数而不是中文字符串是为了排序、统计和并发更新时不产生歧义。判断一套源码是不是课程设计水平看这一个字段就够。排查流程问题时下面这条SQL是基本功它能把“当前用户的待办”和“流程卡在哪一层”一次查清楚-- 查看当前用户的审批待办判断流程卡在哪一层 SELECT w.id, w.title, n.node_name, n.approver_id FROM workflow w JOIN workflow_node n ON n.workflow_id w.id AND n.status 1 WHERE n.approver_id 当前用户ID;这条SQL的核心是n.status 1它筛出的是“当前正在等待审批”的节点。如果上一节点审批通过后下一节点的待办没出现多半是这里关联的approver_id没写对或者workflow_node里根本没有生成下一节点记录。把这条SQL跑一遍是后续所有流程排查的第一步。3. 把PHP开源OA部署到LNMP环境环境配置、数据库初始化与站点上线部署这件事对老手来说是半小时的机械操作对新手来说是第一个大坎。因为这套源码多半不是最新框架写的可能用的是老式mysql_connect或一批已废弃的PHP函数直接用PHP 8.x跑会直接Fatal error。所以环境版本的选择比命令本身更重要。3.1 LNMP环境搭建与PHP扩展老源码优先用PHP 7.4接触过大量二手OA源码后我养成了“先看语法再定版本”的习惯。大多数老源码基于PHP 5.6或7.0的语法写成PHP 8.0开始移除了一批函数、收紧了类型转换直接升级会冒出一堆致命错误。动手之前先用php -l对入口文件做语法检查再决定版本。保守做法是先跑PHP 7.4稳定之后再做8.x迁移评估。在Ubuntu 20.04上安装PHP 7.4及常用扩展add-apt-repository ppa:ondrej/php apt update apt install -y php7.4-fpm php7.4-mysql php7.4-mbstring \ php7.4-xml php7.4-gd php7.4-zip php7.4-bcmath systemctl enable --now php7.4-fpm这里的扩展不是随便装的php7.4-mysqlnd是连接MySQL的驱动老代码里mysqli和PDO都依赖它php7.4-mbstring管中文编码没有它mb_substr这类函数会直接报未定义php7.4-xml提供simplexml和DOMDocumentOA的XML导入、报表导出都靠它php7.4-gd是验证码图片和附件缩略图的基础。如果源码里用了Redis缓存还得加上php7.4-redis否则session入库配置不生效。装完扩展后php.ini里这几个参数必须调否则第一次传附件就会踩坑upload_max_filesize 20M post_max_size 24M max_execution_time 120 memory_limit 256M date.timezone Asia/Shanghaipost_max_size要比upload_max_filesize大因为附件只是POST请求的一部分请求头和其他表单字段也占体积memory_limit给到256M是为了跑报表统计、Excel导出这类吃内存的操作时区不设置的话日志时间戳和业务时间会差8小时排查问题会怀疑人生。改完参数记得systemctl restart php7.4-fpm。3.2 数据库初始化与应用配置从导入SQL到改好config源码包里的install/oa.sql是整套数据库的建表脚本手工一句句执行不是不行但容易漏掉表之间的依赖关系。正确做法是先用命令行建库再整库导入mysql -uroot -p -e CREATE DATABASE oa_system DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; mysql -uroot -p oa_system install/oa.sql字符集这里有个细节老源码默认建库是utf8也就是utf8mb3存生僻字和某些特殊符号时会报“Incorrect string value”错误。我的习惯是建库时直接用utf8mb4但前提是建表SQL里没有写死DEFAULT CHARSETutf8否则导入会按表自己的定义覆盖。导入完成后用SHOW TABLES;看一眼表数量是否和源码文档一致再用SELECT COUNT(*) FROM sys_user;确认基础数据在。接下来改应用配置。老式PHP OA的配置文件常是config/config.php内容是全局数组或一堆define。核心配置块长这样?php // config/config.php 按源码实际位置调整 return [ db [ host 127.0.0.1, port 3306, database oa_system, username oa_user, password 换成强密码, charset utf8mb4, ], session [ name OASESSID, expire 7200, ], upload [ max_size 20971520, // 20MB allowed_ext [jpg, png, pdf, doc, docx, xls, xlsx, zip], ], ];如果源码用的是老式define写法改动的本质是一样的数据库账号密码、session有效期、上传目录和大小限制。需要特别注意数据库连接不要用root账号单独建一个只拥有oa_system库权限的账号这是一道最简单的安全边界。改完配置后访问安装向导或首页能出现登录页说明PHP和MySQL之间的链路通了。提示部分源码安装向导会自动生成管理员账号初始密码写在README里。这种密码上线前必须改尤其是泛微E10这类商业OA曾因初始密码问题被扫过开源OA同样适用这个原则。3.3 Nginx站点配置与伪静态规则让URL不带index.phpPHP内置的php -S只适合本地开发生产环境还是用NginxFPM。站点配置里最核心的是try_files伪静态规则它把/index.php从URL里藏掉同时保证路由能正常分发server { listen 80; root /var/www/oa/public; index index.php index.html; location / { try_files $uri $uri/ /index.php$is_args$args; } location ~ \.php$ { fastcgi_pass unix:/run/php/php7.4-fpm.sock; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; } location ^~ /uploads/ { location ~ \.php$ { deny all; } } }try_files $uri $uri/ /index.php$is_args$args的意思是先找磁盘上的真实文件找不到就把请求转给入口文件由PHP路由解析。fastcgi_pass用的是Unix socket而不是TCP性能更好、少一层网络开销生产环境推荐这种方式。最下面那个/uploads/区块是安全配置它的作用是即使攻击者把PHP文件传到了上传目录Nginx层也直接拒绝执行。这行配置是后来补上的早期做OA部署时没人提这个结果吃过大亏。4. 上线前避坑清单PHP安全与OA二次开发的五个排查点部署完能登录只是开始。真正折磨人的是上线后的安全扫描和流程异常。这一章列五个高频问题每条都是按“现象、原因、解决”来写的基本都是血泪经验换来的。4.1 文件上传与PHP伪协议为什么源码自带的上传接口不能直接裸奔现象测试环境上传图片一切正常上线后过了几天服务器上多了一堆来路不明的PHP脚本。检查访问日志发现有人通过附件接口直接上传了可执行脚本。原因这类OA源码为了易用上传校验只查了后缀名黑名单比如把php拦住了但没拦住php3、phtml或者把文件存到/uploads/后这个目录里PHP解析仍然生效。另一个常见隐患是php.ini里开了allow_url_include配合源码里某些文件包含点就成了PHP伪协议利用链。解决上传校验改成白名单加随机文件名同时保证附件目录里任何PHP文件都不被执行。文件名校验用代码实现?php $ext strtolower(pathinfo($_FILES[file][name], PATHINFO_EXTENSION)); $allowed [jpg, png, pdf, doc, docx, xls, xlsx, zip]; // 白名单 if (!in_array($ext, $allowed, true)) { exit(file type not allowed); } $newName date(Ymd) . / . bin2hex(random_bytes(16)) . . . $ext;bin2hex(random_bytes(16))生成32位随机文件名彻底断掉攻击者“猜路径”的念想白名单比黑名单可靠得多黑名单永远有漏网之鱼。Nginx层再补上3.3里那个deny all配置上传漏洞就被封死了。4.2 XML导入与XXE风险OA里不起眼的导入接口也要管现象安全扫描时发现某个“从XML导入报表”的接口存在外部实体解析风险。原因是老代码解析XML时直接用了simplexml_load_string没有做任何实体限制。原因OA里经常有“外部系统数据导入”“第三方报表解析”这类冷门功能后台权限看着严但如果权限没覆盖到XML里带的DOCTYPE定义会在解析时被展开读取本地文件内容并带到响应里。广联达OA这类产品曾曝出过类似的XXE漏洞开源PHP OA如果复用了老式解析函数风险一模一样。解决解析XML之前显式禁止外部实体加载?php libxml_disable_entity_loader(true); $xml simplexml_load_string($rawXml, SimpleXMLElement, LIBXML_NONET);第一个参数是总开关禁用外部实体加载LIBXML_NONET阻断网络请求双保险。需要注意的是PHP 8.0之后libxml_disable_entity_loader被标记为废弃那时要改用libxml_set_external_entity_loader传一个返回空集的回调函数。老源码跑在7.4上前者够用但代码注释里要留个升级提醒。4.3 登录态失效与多端互踢Session设计没看懂的代价现象用户每隔十几分钟就被踢出登录或者在两个浏览器标签页里开着同一个OA一个标签保存操作另一个标签立刻失效。原因OA这种系统对会话要求高用户填半天表单一提交就掉线问题基本出在Session配置上。要么session.gc_maxlifetime太短PHP回收机制把还在使用的会话清掉了要么源码里的单点登录做得很粗暴每次登录都生成一个新的session_id把旧会话覆盖掉导致同一账号多端使用互相顶号。解决Session生命周期要按业务场景设置不能图省事用默认值同时把Session存到Redis里避免多台机器部署时会话不同步?php ini_set(session.gc_maxlifetime, 7200); ini_set(session.save_handler, redis); ini_set(session.save_path, tcp://127.0.0.1:6379);这里有两个参数要配套看session.gc_maxlifetime控制过期时间session.save_path指向Redis地址。多端互踢的问题根源在于同一用户的多个会话共用了一个session key要彻底解决需要把“用户在线会话表”单独建出来一个用户允许同时存在多个会话记录但后续请求要按会话id而不是按用户id取权限。这是老源码最常缺的一块表。4.4 审批流卡单状态字段不一致导致待办消失现象上一节点审批通过了下一节点的待办列表里没有数据。看数据库workflow表的status已经是2但workflow_node表的下一节点status还是0。流程明明“已通过”后续节点就是没人收到待办。原因源码里“更新流程状态”和“生成下一节点待办”是两条独立的SQL中间没有事务包裹。一旦第一步执行成功、第二步执行失败状态就永久错位。另一个常见原因是状态字段用了中文字符串或备注文本代码里判断值写错了比如存的是“已通过”代码却查“pass”。解决流程状态必须用整数枚举并且把“更新当前节点 生成下一节点待办”放进同一个数据库事务?php $pdo-beginTransaction(); try { $pdo-exec(UPDATE workflow_node SET status 2 WHERE id {$currentNodeId}); $pdo-exec(INSERT INTO workflow_todo (node_id, user_id) VALUES ({$nextNodeId}, {$approverId})); $pdo-commit(); } catch (Exception $e) { $pdo-rollBack(); error_log($e-getMessage(), 3, /var/log/oa_error.log); }事务的意义在于要么两步全部成功要么全部回滚不会出现“中间态”卡死。改造时把日志写进独立的错误文件排查问题时直接看日志比猜代码快得多。4.5 管理员密码丢了不要删库跑路现象部署的人离职了唯一的管理员账号密码没人知道再进不去后台。数据库里的密码是hash不可逆网上搜“忘记密码”也没搜到现成方案。原因老源码安装后没有预留自服务改密入口数据库里也没有备用管理员账号。这时候千万别急着删库重装那意味着所有流程数据和审批记录全部归零这个后悔药找不回。解决写一段CLI脚本直接生成新的密码hash并更新用户表?php $pdo new PDO(mysql:host127.0.0.1;dbnameoa_system, root, 你的数据库密码); $newPassword password_hash($argv[1] ?? Admin123456, PASSWORD_BCRYPT); $stmt $pdo-prepare(UPDATE sys_user SET password ? WHERE id 1); $stmt-execute([$newPassword]); echo password updated, new hash: {$newPassword}\n;$argv[1]是命令行传入的新密码没传就用默认值兜底跑完立刻修改。这个脚本上线前就要准备好放在运维目录里因为谁都有记错密码的时候。5. 把OA改顺手Excel批量导入、API鉴权与二次开发验证5.1 用Excel批量导入组织架构事务、幂等与字符集三个要点新公司入职一批人手动在后台一个个建账号效率太低。常见做法是把组织架构数据整理成CSV用一段一次性PHP脚本批量导入。CSV比xlsx省事不需要额外装PHPExcel扩展?php $pdo new PDO(mysql:host127.0.0.1;dbnameoa_system, root, ); $rows array_map(str_getcsv, file(users.csv)); $stmt $pdo-prepare(INSERT INTO sys_user (name, mobile, dept_id) VALUES (?,?,?) ON DUPLICATE KEY UPDATE dept_id VALUES(dept_id)); $pdo-beginTransaction(); foreach ($rows as $row) { if (empty($row[0]) || $row[0] 姓名) continue; // 跳过表头 $stmt-execute([trim($row[0]), trim($row[1]), (int)$row[2]]); } $pdo-commit();这段脚本里ON DUPLICATE KEY UPDATE是幂等关键它依赖表里mobile字段的唯一索引重复导入不会生成重复账号只是把部门信息刷新一遍。跳过表头用$row[0] 姓名判断简单直接。字符集方面CSV文件要用UTF-8编码保存用Excel另存为CSV时默认可能是GBK导入前用iconv(GBK, UTF-8, ...)转一下。5.2 给旧版OA的API加一层简单的token签名校验外部系统要调OA的组织架构接口旧源码的接口是裸的知道URL就能访问。最小改动方案是加一层签名校验脚本侧根据token验证请求是否合法?php function api_check() { $token $_GET[token] ?? ; $ts (int)($_GET[ts] ?? 0); $appid oa_api; // 调用方标识 $secret 换成随机长字符串; // 与调用方约定不落库 if (abs(time() - $ts) 300) exit(expired); $sign md5($secret . $ts . $appid); if ($sign ! $token) exit(invalid sign); }逻辑是时间戳ts加密钥拼成字符串再md5服务端算一次对比请求里的token。有效期300秒防止截获后长期重放密钥永远不出现在请求里。这个方法适合内部系统之间的轻量对接如果要对外开放给多个第三方再升级成OAuth体系。我前几年接手一套老PHP OA时一上来就急着改考勤逻辑结果没先验证环境与权限边界上线当周把一个旧接口的密码写死在了代码里回滚折腾了一整晚。之后养成的习惯是先跑通最小部署和安全基线再动业务代码每一次改动都要能用一段可重复的脚本或一次完整审批流程来验收。希望帮到你。本文还有配套的精品资源点击获取