基于php得内部oa办公系统

用PHP写内部OA，基于最直接的内部理由就一个：公司里但凡有台跑着Apache或者Nginx的服务器，扔个PHP文件上去就能跑。系统不用配Node环境，基于不用装JDK，内部不用折腾Python虚拟环境。系统我上一家公司行政部那台2008年的基于戴尔塔式服务器，CentOS 6.5，内部PHP 5.3，系统照样撑起了全公司三百多号人的基于请假、报销、内部会议室预定。系统听起来寒酸，基于但真能用。内部

这套系统的系统核心其实就三块：人员权限、流程流转、数据留痕。听着像废话，但很多OA做烂了就是因为把这三块搅在一起。我见过一个用ThinkPHP 3.2写的考勤模块，管理员和普通员工的判断逻辑写在了同一个控制器方法里，if-else嵌套了七层，改一个请假规则得翻两百行代码。后来重构，把权限抽象成角色表加节点表，流程拆成独立的审批链，代码量直接砍掉四成。

数据库设计上，别一上来就搞什么EAV模型。见过一个OA把用户信息拆成user、user_attr、attr_def三张表，查个部门经理的名字要join五次。MySQL的json字段从5.7开始就够用了，简单的扩展属性直接塞一个extra_json列，省事得多。真正需要索引的字段——工号、部门ID、审批状态——老老实实建B+树索引。报销单金额这种要范围查询的，加个复合索引（status, amount），比什么花哨的分表策略都管用。

审批流是OA里最容易写崩的地方。早期我用过递归查上级，A的经理是B，B的经理是C，C的经理是D……遇到组织架构调整，某个人的上级指到了自己，直接死循环。后来改成闭包表（closure table），把层级关系预计算存下来，查“张三的所有上级”就是一条select。代价是每次人员变动要更新闭包表，但内部OA人员变动频率低，这点开销完全能接受。审批节点加个sign_type字段区分会签、或签、依次审批，前端根据这个字段渲染不同的按钮组，后端只认最终状态，逻辑清爽很多。

文件上传是个坑。PHP默认的upload_max_filesize是2M，post_max_size是8M，报销单拍个发票照片就超了。改php.ini当然可以，但虚拟主机不一定让你改。稳妥的做法是前端用FileReader做分片，后端用move_uploaded_file配合临时目录，每片存一个tmp文件，最后合并。会议室预定那块反而简单，一张reservations表，start_time和end_time建联合唯一索引，插入时捕获Duplicate entry异常，提示“该时段已被占用”。比先select再insert靠谱，并发下不会超卖。

安全方面，别迷信什么框架自带的XSS过滤。内部OA最大的风险是越权——普通员工通过改URL里的id参数看到了别人的工资条。每个涉及数据的接口，第一行就得写权限校验：当前用户ID能不能操作目标资源。我习惯在基类控制器里放一个checkAuth($resourceId, $action)方法，子类必须调用。SQL注入反而好防，PDO预处理绑参数，别手拼字符串就行。

最后说个观察：内部OA的生命周期通常不超过三年。业务一变，流程就得改，改到后来代码里全是if($deptId == 3 && $amount > 5000)这种硬编码。与其追求大而全，不如把审批引擎做成可配置的——流程节点、跳转条件、通知模板全存数据库表里，加一条新规则就是插一行数据。PHP写这种配置驱动的逻辑其实很顺手，数组加闭包，比Java的注解灵活得多。代码丑点没关系，能跑、好改、不出事，内部系统要的就是这个。

本文地址：http://www.79wt.cn/news/842a1699141.html