企业官网建设流程全解析

简介：信呼协同办公OA系统开源版v2.1.7是一套面向中小企业、团队及开发者的一体化办公解决方案，支持APP、PC网页版与PC客户端多端协同，数据完全由企业自行管理，适合需要私有化部署、二次开发或搭建内部工作流的用户。压缩包共1332个文件，约2.95MB，以653个PHP文件为核心业务逻辑，配合164个HTML页面、159个JavaScript脚本与19个CSS样式表构建前端交互，另有GIF、PNG等图像资源及SQL建库文件、字体与音视频素材，结构完整可直接部署。该版本重点完善了系统安全性并做整体优化，新增问卷调查、退货单等实用模块，同时保留自定义应用、模块数据与权限分配能力，支持单据快速提醒推送和即时信息沟通。目前已有271人学习下载，读者可借此获得一套可运行的开源OA源码，用于研究跨平台办公系统的架构设计、权限体系与模块扩展方式，也便于在此基础上进行功能定制与二次开发。

1. 信呼协同办公OA系统开源版v2.1.7：一套代码如何同时喂饱APP、网页和PC客户端

很多团队在选型协同办公系统时，第一反应是“直接买SaaS”，但真到了要对接内部老旧数据库、要私有化部署、要按自己业务流程改字段的时候，SaaS的边界就露出来了。信呼协同办公OA系统开源版v2.1.7这个包，解决的就是这类问题：它把服务端、网页端、APP端和PC客户端放在同一个代码仓库里，用一套后端接口支撑三种前端形态。适合谁？适合有PHP开发能力、需要私有化部署、又不想从零写工作流引擎的中小团队。你拿到的是一个能跑起来的完整骨架，而不是一个只能看的演示。它的价值不在于功能有多全，而在于“三端同源”这个结构——改一处业务逻辑，APP和PC客户端不用重新发版就能生效。这也是我当初愿意花时间拆它的原因。

2. 三端同源到底怎么实现的：从入口文件到接口分发

2.1 目录结构里藏着的端侧分离逻辑

拿到压缩包解压后，第一件事不是急着配数据库，而是先看目录。信呼的根目录下通常会有web、app、client三个平级目录，外加一个api或interface目录。这个结构直接告诉你：网页版是独立的一套PHP页面，APP端和PC客户端共用同一套HTTP接口。我一般会先打开api目录下的入口文件，看它怎么区分请求来源。

// api/index.php 简化示意 $clientType = $_SERVER['HTTP_X_CLIENT_TYPE'] ?? 'web'; // 根据请求头区分是APP、PC客户端还是网页AJAX switch ($clientType) { case 'app': $response = handleAppRequest($action, $params); break; case 'pc': $response = handlePcRequest($action, $params); break; default: $response = handleWebRequest($action, $params); } echo json_encode($response);

这段逻辑说明：服务端并不为每个端写一套控制器，而是通过请求头里的X-Client-Type做分发。参数说明上，$action对应具体业务动作，比如get_user_info、submit_flow；$params是统一格式的数组。你改业务逻辑时，只要改handleAppRequest和handlePcRequest共用的底层模型，两端就同时生效。常见做法是把共用逻辑抽到model层，端侧只做数据格式转换。

2.2 数据库配置与最小化启动步骤

信呼的安装向导通常要求你填数据库连接信息。我建议不要用root账号跑，单独建一个库和用户。步骤如下：

第一步，创建数据库和用户：

CREATE DATABASE xinhu_oa DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; CREATE USER 'oa_user'@'localhost' IDENTIFIED BY '你的强密码'; GRANT ALL PRIVILEGES ON xinhu_oa.* TO 'oa_user'@'localhost'; FLUSH PRIVILEGES;

第二步，把压缩包里的config目录下的database.php.example复制为database.php，填入上面的库名、用户名和密码。注意字符集必须用utf8mb4，否则APP端发emoji会直接写库失败，这是血泪经验。

第三步，通过浏览器访问http://你的域名/install走安装流程。安装程序会导入基础表结构和初始管理员账号。这里有个坑：如果PHP版本高于7.4，部分老式写法会报Deprecated警告，但不影响安装，装完后在php.ini里把display_errors关掉即可。

2.3 接口鉴权与三端登录态的统一

三端同源最大的难点是登录态。网页版用Session，APP和PC客户端通常用Token。信呼的做法是在用户表里存一个api_token字段，APP登录成功后服务端返回Token，后续请求放在Header里。网页版则继续用Session，但接口层会同时检查两者。

// 鉴权中间件简化逻辑 function checkAuth() { $token = $_SERVER['HTTP_AUTHORIZATION'] ?? ''; if ($token) { // APP或PC客户端走Token验证 $user = getUserByToken($token); } else { // 网页版走Session session_start(); $user = getUserBySessionId(session_id()); } if (!$user) { http_response_code(401); exit(json_encode(['code' => 401, 'msg' => '未登录'])); } return $user; }

参数说明：HTTP_AUTHORIZATION是APP端在登录后拿到的Token，PC客户端同理。网页版不传这个头，走Session。这样一套鉴权代码覆盖三端，不用维护三份。你唯一要注意的是Token过期时间，建议在config里设成7天，太短APP用户老要重新登录，太长有安全风险。

3. 把OA跑起来之后：工作流、消息推送和文件存储的落地配置

3.1 工作流引擎的表单绑定与节点设置

信呼的工作流是它比较核心的模块。你可以在后台“流程管理”里新建一个流程，然后绑定表单。表单字段是存在flow_form表里的，每个字段有field_name、field_type、field_value。我一般会先建一个最简单的“请假申请”流程来验证整条链路。

操作路径：后台 → 流程管理 → 新建流程 → 绑定表单 → 设计节点。节点分三种：发起节点、审批节点、结束节点。审批节点要指定审批人，可以是固定人，也可以是发起人的直属上级。这里有个参数叫flow_type，1表示固定流程，2表示自由流程。固定流程适合请假、报销这种标准场景，自由流程适合临时任务。

// 流程提交时的核心参数组装 $flowData = [ 'flow_id' => 1, 'user_id' => $currentUser['id'], 'form_data' => json_encode($formFields, JSON_UNESCAPED_UNICODE), 'status' => 0, // 0待审批 1通过 2驳回 'create_time' => time(), ]; // 写入flow_run表，然后触发消息推送

逻辑说明：form_data用JSON存，方便后续扩展字段不用改表结构。status是流程状态，审批人操作后更新这个字段。消息推送在写入后立即触发，推给下一个节点的审批人。

3.2 APP端消息推送的两种通道配置

APP端要收到审批通知，需要配置推送通道。信呼开源版通常支持两种：轮询和长连接。轮询最简单，APP每隔30秒请求一次api/get_new_message，有数据就弹通知。长连接需要额外开一个WebSocket服务，对服务器有要求。

我一般先用轮询跑通，因为配置成本低。在APP的配置文件里找到push_interval，默认可能是60秒，改成30秒。服务端在message表里加一个is_push字段，0表示未推送，1表示已推送。轮询接口只查is_push=0的记录，返回后立即更新为1。

// api/get_new_message.php 核心逻辑 $messages = $db->query("SELECT * FROM message WHERE user_id = ? AND is_push = 0", [$userId]); if ($messages) { $db->query("UPDATE message SET is_push = 1 WHERE id IN (" . implode(',', array_column($messages, 'id')) . ")"); } echo json_encode(['code' => 0, 'data' => $messages]);

参数说明：user_id从Token解析出来，is_push是幂等标记，防止同一条消息重复弹窗。注意并发情况下可能重复推送，但OA场景对重复推送容忍度较高，不用上锁。

3.3 文件存储：本地磁盘还是对象存储

OA系统离不开附件上传。信呼默认存本地upload目录，按日期分文件夹。小团队用本地磁盘没问题，但如果你要部署多台服务器做负载均衡，本地存储就会导致A服务器上传的文件B服务器读不到。

常见做法是改成对象存储。信呼的upload类里有一个save方法，你可以重写它，把文件流直接传到对象存储，数据库里只存URL。如果不想改代码，也可以把upload目录通过NFS挂载到共享存储。我一般会先看团队规模：50人以下单机部署，本地磁盘足够；超过100人或者要多节点，直接上对象存储，别犹豫。

// 重写upload类的save方法示意 public function save($file) { $objectKey = date('Ymd') . '/' . uniqid() . '.' . pathinfo($file['name'], PATHINFO_EXTENSION); // 调用对象存储SDK上传 $url = $this->ossClient->upload($objectKey, $file['tmp_name']); return $url; }

逻辑说明：$objectKey按日期分目录，避免单目录文件过多。uniqid保证文件名不冲突。返回的URL直接存数据库，前端展示时直接用。注意要设置好对象存储的跨域规则，否则网页版上传会报CORS错误。

4. 避坑与排查：三端联调时最容易翻车的五个地方

4.1 APP端登录成功但接口全部返回401

现象：APP输入账号密码提示登录成功，但紧接着请求用户信息就返回401。原因通常是Token没有正确回传。检查APP的HTTP请求拦截器，看登录接口返回的token字段有没有存到本地，后续请求有没有放到Authorization头里。解决：在拦截器里统一加config.headers.Authorization = 'Bearer ' + token。注意有些APP框架默认不带这个头，需要手动加。

4.2 网页版上传附件提示“文件类型不允许”

现象：上传PDF或图片时提示类型不允许，但后台明明设置了允许。原因多半是PHP的fileinfo扩展没开，或者upload_max_filesize太小。解决：在php.ini里把upload_max_filesize和post_max_size都改成20M以上，重启PHP。然后检查fileinfo扩展是否启用，没启用就装上。信呼的MIME检测依赖这个扩展。

4.3 工作流审批后状态不更新

现象：审批人点了“通过”，但流程状态还是待审批。原因通常是审批接口的flow_run_id传错了，或者数据库事务没提交。解决：打开浏览器的开发者工具，看审批请求的响应里code是不是0。如果不是，看msg提示。常见的是flow_run_id为空，检查前端有没有从URL里取对参数。另外确认MySQL的存储引擎是InnoDB，MyISAM不支持事务。

4.4 PC客户端启动后白屏

现象：PC客户端安装后打开是白屏，没有任何报错。原因一般是客户端内置的浏览器内核版本太低，不支持某些ES6语法。解决：找到客户端的配置文件，看有没有enable_node_integration之类的选项，关掉它。或者把服务端的接口返回改成ES5兼容格式。我一般会先用网页版访问同一套接口，如果网页版正常，那就是客户端内核问题。

4.5 定时任务不执行导致消息积压

现象：系统运行几天后，消息表里is_push=0的记录越来越多，APP收不到通知。原因通常是服务器的crontab没配，或者PHP CLI路径不对。解决：在服务器上执行crontab -e，加一行* * * * * /usr/bin/php /path/to/oa/cron/push_message.php。注意/usr/bin/php要换成你实际的PHP CLI路径，用which php查。配完后手动跑一次脚本，看有没有输出错误。

5. 进阶：用接口日志和慢查询把OA性能问题钉死在萌芽期

跑通之后，真正让人头疼的不是功能，而是“用着用着就慢了”。我一般会在上线前做两件事：开接口日志和开慢查询日志。接口日志记录每个请求的action、耗时、用户ID，慢查询日志记录执行超过1秒的SQL。这两个日志配合看，基本能定位90%的性能问题。

先看接口日志怎么加。在api/index.php的入口处，记录开始时间和结束时间：

$startTime = microtime(true); // ... 业务逻辑执行 ... $endTime = microtime(true); $cost = round(($endTime - $startTime) * 1000, 2); // 毫秒 // 写入日志文件，按天分文件 file_put_contents( '/var/log/oa_api_' . date('Ymd') . '.log', date('Y-m-d H:i:s') . ' | ' . $action . ' | ' . $cost . 'ms | user:' . $userId . PHP_EOL, FILE_APPEND );

参数说明：$action是请求的动作名，$cost是耗时毫秒数。日志按天分文件，方便清理。跑一周后，用awk统计一下哪些action平均耗时最高：

awk -F'|' '{print $2, $3}' /var/log/oa_api_20250101.log | sort | awk '{sum[$1]+=$2; count[$1]++} END {for (a in sum) print a, sum[a]/count[a]"ms"}'

这条命令会输出每个动作的平均耗时。如果某个动作超过500ms，就要去看对应的SQL了。

慢查询日志在MySQL里开：

SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 1; SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';

然后分析慢查询日志，用mysqldumpslow或者直接看。常见的问题是flow_run表没有索引，导致审批列表查询全表扫描。加一个联合索引：

ALTER TABLE flow_run ADD INDEX idx_user_status (user_id, status);

这个索引让“查某个用户的待审批流程”从全表扫描变成索引查找，通常能快10倍以上。

还有一个容易忽略的点：APP端的图片上传。如果用户直接传原图，一张5MB的照片会让上传接口耗时超过3秒。我一般会在APP端做压缩，或者服务端收到后异步压缩。服务端压缩可以用GD库：

// 上传后异步压缩示意 $image = imagecreatefromjpeg($tmpFile); $compressed = imagejpeg($image, $targetFile, 75); // 75%质量 imagedestroy($image);

参数说明：75是JPEG质量，75%通常肉眼看不出差别，但文件大小能减少60%以上。注意PNG要用imagepng，质量参数是0-9，不是百分比。

最后说一个我自己的习惯：每次改完代码，不要只测功能，一定要用ab或wrk压一下核心接口。比如登录接口、流程提交接口，并发50跑30秒，看平均响应时间和错误率。如果错误率超过1%，说明有资源竞争或者连接池不够。这个习惯帮我提前发现过好几次数据库连接数打满的问题。希望帮到你。

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