致远A8+ V9.0集团版私有化部署环境配置与排障指南

简介：面向企业信息化管理员、协同办公实施顾问及致远产品使用者的A8+ V9.0集团版用户操作手册，聚焦多组织架构下的协同办公落地，帮助读者解决客户端环境配置、协同事项处理、会议与工作计划流转等日常操作问题，也可作为新员工上手与内部培训的参考资料。包内为1份PDF文档，压缩包约374.29MB，内容从手册结构说明、客户端环境配置到快速使用指南逐层展开，覆盖新建与跟踪协同事项、发出会议通知与提交回执、建立及回复工作计划等操作环节，并延伸至表单、工作流、门户与移动协同等应用场景。手册同时交代了协同“九宫格”所强调的组织目标、业务管控、团队管理与沟通协作等理念，便于读者把功能操作与集团管控思路对应起来。已有496人学习，适合需要按章节查阅、系统梳理集团版功能边界的读者留存备查。

1. 从「装完打不开」说起：A8+ V9.0 集团版的第一个版本坑

致远 A8+ 协同管理软件 V9.0 用户操作手册（集团版）电子版摆在面前时，多数人第一反应是翻到「快速使用指南」，照着点一遍就算把环境摸熟了。真到私有化部署现场，情况往往反着来：服务端起得来，登录页也能打开，可业务同事一进协同事项就白屏，附件上传按钮点下去毫无反应，表单里的日期控件弹不出来。这不是服务端没装好，而是客户端环境配置那一章被跳过了——手册第二章只占两页纸，却是施工现场返工率最高的一段。

集团版这套环境的日常形态是「一台应用服务器 + 一套数据库 + 一批浏览器终端」，看似轻，实际牵扯 JDK 大版本、中间件、数据库字符集、浏览器内核、办公控件五条线，任意一条错位都会表现成「页面打不开」这种没有信息量的症状。这篇记录写给三类人：要做集团版测试环境的开发者、要接手旧环境迁移的实施同学、以及被业务部门追着问「为什么我的电脑打不开」的运维。

2. 装之前先对表：A8+ V9.0 集团版的环境清单与版本取舍

安装包解压出来只是第一步。真正决定这套环境能不能稳的，是装之前那张对照表——服务端三项、客户端三项，对不上就别急着跑安装程序。

2.1 服务端：JDK、中间件、数据库三件套怎么定

服务端的版本选择原则只有一条：以随安装包发布的部署说明为准，不要自作主张追新。A8+ V9.0 这一代产品，行业里常见做法是 JDK 8 系列配 Tomcat 一类轻量中间件，数据库走 MySQL 或 Oracle 两条路，集团版因为组织层级深、流程实例多，数据库选型基本会被 DBA 一票否决成 Oracle 或高配 MySQL。我一般拿到包的第一件事是翻包内的环境要求文件，把 JDK 大版本、中间件大版本、数据库大版本三项抄下来贴在部署单上，后面所有排查都对照这三项。

内存和磁盘的规划比版本更容易被忽略。协同系统的附件增长速度快得离谱，一个集团几百人天天传合同、传报表、传会议材料，半年就能吃掉一块盘。所以安装目录和附件存储目录必须分开挂载，附件盘用独立分区或者独立存储卷，扩起来不用停机搬数据。应用服务器的内存按并发用户数抬，测试环境 8G 起步能跑通，生产环境按实际并发往上加，不要拿测试机的配置单直接上生产。

# 服务端上线前的基础体检，四项里有一项对不上就先别装 java -version # JDK 大版本必须和随包部署说明一致，不要用最新 LTS 顶替 free -g # 看可用内存，测试环境不低于 8G，生产按并发抬 df -h /opt /data # 安装目录与附件目录必须分开挂盘，附件增长最快 ss -lntp | grep -E ':(8080|8005)' # 端口占用先查清楚，别等启动失败再回头翻日志

这四条命令看着简单，价值在于把「装完才发现」的问题提前到「装之前发现」。JDK 版本不对的典型表现是中间件启动时报类版本不兼容，日志里一串 UnsupportedClassVersionError，很多人第一反应是重装中间件，实际是 JDK 装错了大版本。端口占用更常见，8005 这个中间件管理端口经常被上一套没清干净的实例占着，启动脚本不报错，页面就是打不开。

2.2 客户端：浏览器内核与办公插件的硬要求

客户端这一侧才是返工重灾区。协同系统的表单、流程图、正文编辑器大量依赖浏览器能力，A8+ V9.0 这一代对浏览器内核有明确要求，现代内核浏览器是主力，老版本 IE 只能靠兼容模式顶一阵，而且兼容模式一开，部分控件又会失效。实际现场最常见的组合是：统一推现代内核浏览器，把系统地址加入受信任站点，关闭对本地控件的拦截策略。

办公插件是第二个坑。正文编辑、套红、盖章、Word 在线编辑这些功能，靠的是本地装一个 Office 集成控件。控件装不上，页面上的编辑按钮就是灰的；控件装上了但浏览器拦了加载项，按钮能点但点了没反应。这类问题没有报错弹窗，只能靠 F12 看控制台有没有插件加载失败的提示。

我用一张表把客户端要求固定下来，实施时直接发给业务部门照着自查，比口头讲十遍管用：

2.3 把手册第二章翻成一张可勾选的环境对照表

手册里「客户端环境配置」那一章写得偏说明性，直接发给业务部门没人看得懂。我的做法是把它翻译成一张勾选表，每一条都是一个可执行动作：浏览器版本是否达标、系统地址是否加入受信任站点、办公控件是否安装成功、控件版本是否与服务端匹配、附件上传目录是否有写权限、打印控件是否可用。装完一项勾一项，全部勾完再让业务同事登录。

这张表还有个副作用：出问题时能快速定位是「没配」还是「配错了」。没配的表单是空的，配错了的表单是勾了但现象还在，两种情况的排查路径完全不同。前者补配置，后者查版本冲突。

3. 落地部署：从安装包解压到登录页出得来

环境对完表，进入真正的安装动作。这一段的节奏是：先规划目录和账号，再建库，再跑安装程序，最后配访问入口。顺序错了会很麻烦，比如先装了应用再改数据库字符集，等于推倒重来。

3.1 安装前的目录与账号规划

目录规划的核心是「三个分离」：程序目录、附件目录、日志目录分开放。程序目录升级时会被覆盖，附件目录不能动，日志目录要能被日志采集工具单独读取。我一般这么划：

# 目录规划示例，路径按实际磁盘挂载调整 mkdir -p /opt/a8plus/app # 程序目录，升级时整体替换 mkdir -p /data/a8plus/attach # 附件目录，独立磁盘，只增不减 mkdir -p /data/a8plus/logs # 日志目录，单独挂载便于采集与清理 mkdir -p /data/a8plus/backup # 备份目录，数据库与附件分开备份 # 专用运行账号，不要用 root 跑应用 useradd -r -s /sbin/nologin a8run chown -R a8run:a8run /opt/a8plus /data/a8plus chmod -R 750 /data/a8plus/attach # 附件目录权限收紧，只给运行账号读写

这段脚本的重点不在命令本身，在权限模型。用 root 跑应用是最常见的偷懒做法，出问题时进程权限过大，附件目录被误删都追不回来。专用账号加 750 权限，运行账号能读写，其他账号连目录都进不去，日志里出现异常访问也能第一时间发现。

还有一个容易漏的点：临时目录。协同系统的导入导出、附件打包、报表生成都会往临时目录写大量文件，系统默认的 /tmp 分区往往很小，跑几个大附件上传就满了，表现成「上传到 90% 失败」。我习惯单独挂一个 /data/tmp 并改运行账号的临时目录指向。

3.2 数据库建库与服务端安装

建库这一步，字符集必须一次到位。集团版数据量大、历史数据多，后期改字符集基本等于重建环境。行业常见做法是建库时直接用 utf8mb4 字符集，排序规则用通用型，避免大小写敏感带来的登录名匹配问题。

-- 建库语句，字符集与排序规则一次定死，后期不改 CREATE DATABASE a8plus_group DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_general_ci; -- 专用数据库账号，只授权本库，不要给 root CREATE USER 'a8app'@'10.%' IDENTIFIED BY '强密码自行替换'; GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER, REFERENCES ON a8plus_group.* TO 'a8app'@'10.%'; FLUSH PRIVILEGES;

参数说明几句：字符集选 utf8mb4 是为了兼容四字节字符，组织名称、人员姓名里出现生僻字时不会插入失败；排序规则选 general_ci 是大小写不敏感，账号登录、模糊查询都更符合直觉。授权网段写 10.% 是限制应用服务器网段，不要用 % 全开，数据库端口暴露给全内网是安全事故的常见起点。

建完库跑安装程序，安装向导里会让你填数据库连接、管理员账号、License 文件、附件目录。这里有两个注意点：附件目录要填你提前建好的独立挂载路径，别用默认路径；管理员账号不要用 admin 这种默认名，集团版管理员权限极大，能改组织架构、能看全量流程，默认名等于把门牌号写在门上。

安装程序跑完后不要急着让业务登录，先看启动日志。日志里出现数据库连接池初始化成功、缓存服务连接成功、定时任务加载完成这三条，才算服务端真正起来了。

3.3 集团版多级组织的初始化配置

集团版和普通版的差别就在组织层级。集团版通常是「集团总部 — 二级单位 — 三级部门」多层结构，管理员也分级：集团管理员管全局，单位管理员只管本单位，部门管理员只管本部门。初始化时这个层级没建对，后面所有权限都是歪的。

初始化顺序建议是：先建单位，再建部门，再导人员，最后配角色。人员导入支持表格模板批量导入，模板里的单位编码、部门编码必须和系统里已建的完全一致，差一个字符就整批失败，而且报错信息往往只提示「第 N 行数据错误」，不告诉你是哪个字段。我一般先导 3 条测试数据验证模板格式，通过了再导全量。

角色配置是另一个易错点。集团版里同一个岗位在不同单位可能对应不同角色，比如「办公室主任」在总部是审批角色，在分公司可能只是知会角色。角色不要按岗位名建，按权限集合建，岗位映射到角色，人员变动时只改映射关系。

3.4 反向代理与访问入口配置

生产环境很少让用户直连应用端口，中间会加一层反向代理统一入口，好处是能上证书、能做访问日志、能限流。集团版的反向代理配置有几个硬要求：大附件上传要放开请求体大小限制，长连接要调超时，WebSocket 要透传，否则在线消息、流程提醒这类功能会静默失效。

# 反向代理核心片段，只列容易配错的几项 server { listen 443 ssl; server_name协同.example.internal; # 换成实际内网域名 client_max_body_size 500m; # 附件上传限制，默认 1m 会直接 413 location / { proxy_pass http://10.0.0.11:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_read_timeout 600s; # 长流程、大报表导出容易超时 proxy_send_timeout 600s; } location /websocket/ { # 在线消息通道，必须透传 Upgrade 头 proxy_pass http://10.0.0.11:8080; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } }

参数里最容易被漏掉的是 client_max_body_size，默认 1m，业务传个合同附件直接返回 413，前端只提示「上传失败」，后端日志里什么都没有。proxy_read_timeout 默认 60 秒，流程流转、报表导出这类操作经常跑过 60 秒，超时后前端报错但后端其实还在跑，数据状态就对不上了。WebSocket 那一段如果不配，页面看着正常，在线提醒和即时消息永远不会弹。

4. 客户端环境配置：手册第 23 页那一段真正要落的事

服务端跑通只是让登录页出得来，用户能不能干活全看客户端。这一段是手册里写得最简、现场踩坑最多的部分，我按「浏览器—控件—移动端」三条线拆开落地。

4.1 浏览器兼容与安全站点设置

现代内核浏览器默认会拦截混合内容、限制本地控件加载、禁用某些脚本能力，这三条正好都踩在协同系统的功能点上。落地做法是三条：把系统地址加入受信任站点、允许该站点加载本地控件、允许该站点弹出窗口（打印、附件预览会用到）。

企业环境里浏览器策略通常由域控统一下发，手工改一台两台没意义。我的做法是让 IT 出一份浏览器策略文件统一下发，策略里固定三项：受信任站点列表包含系统域名、本地控件加载策略放行、禁止浏览器自动升级到未验证的大版本。最后一条尤其重要，浏览器一年升好几个大版本，某次升级后控件加载策略变了，全公司同时打不开正文编辑器，这种事故一年能遇上一回。

个人开发者在自己机器上验证，手工改就行，路径是浏览器设置里的站点权限，把系统地址加进去，刷新页面再试。判断有没有生效有个简单办法：F12 打开控制台，看有没有 blocked 或 mixed content 字样的告警，有就是策略没放行。

4.2 办公控件与文档在线编辑

办公控件是客户端配置里最玄学的一环。控件本身是个本地程序，通过浏览器插件机制加载，服务端版本、控件版本、浏览器版本三者必须对齐。常见做法是控件随服务端一起分发，用户首次访问时页面提示下载安装，装完重启浏览器。

控件装好后要做三件事验证：新建一条协同事项，看正文编辑器能不能打开；上传一个 Word 附件，看能不能在线预览；打开一个有手写签批的流程，看签批区能不能正常显示。三项都通过，控件才算真正可用。只测第一项是不够的，预览和签批走的是不同控件模块。

控件升级是另一个雷区。服务端升级后控件往往也要跟着升，但已经装过旧控件的电脑不会自动更新，表现成「一部分人能编辑，一部分人打不开」。我一般把控件版本号写进上线检查单，服务端升级当天同步推送新控件，并且在系统公告里挂一条「请清理浏览器缓存后重新安装控件」。

4.3 移动端接入与多终端一致性

移动端不是简单装个 App 就完事。移动客户端要绑定服务端地址，内网环境还得配证书信任，公网访问要走统一入口。绑定失败的典型表现是登录时提示网络异常，实际是客户端不信任内网自签证书。常见做法是把根证书随客户端配置一起下发，或者在有条件的情况下用受信任证书。

多终端一致性是集团版特有的问题。同一条协同事项，PC 端能打开、移动端打不开，八成是移动端门户没配或者流程节点不支持移动端处理。手册里移动端门户设置那一节讲的就是这个——PC 端门户和移动端门户是两套配置，新建的流程模板如果只配了 PC 门户，移动端用户看到的就是一片空白。上线前我习惯用同一个测试账号在 PC、手机、平板各跑一遍完整流程，三端行为不一致就回到门户配置里查。

5. 排查与避坑：装完跑不起来的五类现场

5.1 登录页能打开，进协同事项白屏

现象：账号密码输进去，首页框架出来了，点「协同工作」菜单，右侧内容区一片空白，控制台报脚本加载 404。

原因：反向代理只转发了一部分路径，静态资源目录没配进去，或者代理规则里 location 写得太窄，把 /static 这类路径漏掉了。另一种情况是浏览器缓存里存着旧版本的前端资源，服务端升级后文件名变了，旧缓存引用失效。

解决：先看浏览器网络面板里哪个请求 404，把那个路径补进代理规则；确认代理没问题后，让用户强制刷新清缓存。上线后前端资源带版本号的情况下，在代理层给静态资源加长缓存，页面入口文件禁止缓存，能同时兼顾加载速度和升级一致性。

5.2 附件上传到一半失败，无任何报错

现象：大附件上传进度条走到某个百分比卡住，最后提示上传失败，服务端日志里没有异常记录。

原因：反向代理的请求体大小限制默认 1m，超过直接拒绝，请求根本没到应用层，所以应用日志里什么都没有。另一个可能是附件目录所在磁盘满了。

解决：代理层放开 client_max_body_size，应用层确认上传大小限制参数，磁盘层面加监控。这三个位置任何一处卡住都表现成同一个症状，排查顺序建议从外到内：先看代理日志有没有 413，再看磁盘使用率，最后看应用参数。

5.3 流程能发起，待办列表里看不到

现象：发起人提交成功，审批人登录后待办事项里空空如也，但流程实例在流程监控里是运行状态。

原因：审批人所在组织层级和流程节点的选人规则不匹配，比如节点配置的是「部门主管」，但该部门没有配置主管岗位，流程实例创建了却找不到接收人，卡在待办生成环节。

解决：进流程监控看实例的当前节点和执行人，执行人为空就是选人规则没匹配上。回到组织架构里补岗位配置，或者在流程节点上换成更明确的选人方式。集团版里单位管理员和部门管理员的权限边界也要一并检查，跨单位流程的节点选人规则经常被配成本单位范围。

5.4 正文编辑器打不开，按钮是灰的

现象：新建协同事项，正文区域显示「控件未安装」或者干脆空白，编辑按钮点不动。

原因：办公控件没装、装错版本、被浏览器策略拦截，三种情况表现几乎一样。区别在于控制台报错内容不同：没装是「对象未定义」，版本不对是「方法不存在」，被拦截是「加载被阻止」。

解决：按这个顺序查——控制台报错内容判断大类，控件版本号和服务端要求比对，浏览器策略文件确认放行。三个都排除还不行，换一台没装过控件的电脑试，能复现就是服务端分发问题，不能复现就是那台机器本身的残留问题。

5.5 移动端提示网络异常，PC 端正常

现象：同一个账号 PC 端登录正常，移动客户端绑定地址后提示网络异常，换了 WiFi 和移动网络都一样。

原因：移动客户端对服务端证书的校验比浏览器严格，内网自签证书默认不被信任；另一种情况是移动端门户没配，客户端能连上服务端但拉不到首页配置。

解决：先确认客户端是否能访问服务端的健康检查地址，能访问说明网络通，问题在证书或门户配置。证书问题把根证书下发给客户端安装；门户问题到后台确认移动端门户是否启用、是否绑定到对应单位。集团版里不同单位可以配不同移动门户，绑定错单位也会表现成空白页。

6. 验证：用一条真实协同流程把环境跑穿

装完不等于跑通，跑通不等于好用。我验证一套 A8+ V9.0 集团版环境，从来不看登录页能不能打开，而是用一条从发起到归档的完整流程把整条链路走穿。

第一步是服务端自检，用命令行确认三个对外端点都有正常响应：

# 服务端三连检，返回 200 才算服务端真起来了 curl -I -k https://协同.example.internal/ # 登录页，验证代理与证书链路 curl -I -k https://协同.example.internal/health # 健康检查，验证应用内部依赖 curl -I -k https://协同.example.internal/static/ # 静态资源，验证代理路径没漏

这三条命令的价值在于分层定位。第一条通、第二条不通，说明代理没问题、应用内部依赖有问题，去查数据库和缓存连接；第一条通、第三条 404，说明代理规则漏了静态资源路径，页面能打开但样式全丢，用户看到的是纯文本界面。

第二步是业务链路验证，用两个不同单位的测试账号跑一遍：A 账号发起一条跨单位协同，B 账号在待办里收到并处理，回到 A 账号看已办是否同步，最后在流程监控里确认实例状态是已结束。这条链路能同时验证组织架构、选人规则、跨单位权限、待办生成、消息通知五个环节，任何一个环节断了都能立刻暴露。

第三步是多端一致性验证，PC 端建一条带附件的协同，移动端打开看附件能不能预览、正文能不能看，平板再走一遍。三端表现不一致就回到门户配置里查，别在客户端上反复卸载重装。

第四步是回头验证客户端环境配置清单。把第二章那张勾选表拿出来，逐项在实际终端上确认一遍：浏览器版本、受信任站点、控件版本、上传下载、打印预览。这一步最枯燥，但返工最少——我见过太多环境服务端完美、客户端一塌糊涂，上线第一天全公司报故障。

从那以后我每次部署完，不管多晚，都要用一条跨单位流程把环境从头到尾走一遍，走不通就不通知业务上线。这套动作花不了二十分钟，能省掉后面几天的救火。希望帮到你。

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