EOS移动端隐藏流程发起按钮的四种方案：配置、权限、前端开发与缓存排查

1. 去掉"流程发起"之前，先想清楚你要哪种"去掉"

1.1 三种不同深度，对应三种工作量

在EOS 8.3.2的移动端后台管理群里，隔三差五就能看到这个问题：底部那个"流程发起"能不能去掉？提这个问题的，十有八九是刚把移动办公应用推到业务部门的实施人员，或者甲方信息中心的运维负责人。先给个结论：能去，但不是每种"去掉"都一样。

同样是"去掉底部流程发起"，实际需求可以差出三个深度等级。

第一种是隐藏入口。用户打开移动端首页，看不到"流程发起"这个按钮，但如果有人确实有发起权限，通过其他路径（比如流程中心、业务系统内嵌入口）依然能发起流程。这种改法最轻，涉及的是首页展示逻辑，通常改配置就能实现。

第二种是禁用功能。不仅入口看不到，相关的发起页面、发起操作也都要按角色受限。某个角色哪怕拿到流程发起页的完整地址，也打不开、发不了。这种需要前端隐藏加后端权限双管齐下。

第三种是彻底移除。整个移动端的流程发起相关能力从代码层面不再加载，首页、路由、接口都不再处理这部分逻辑。这种多半出现在客户要把移动端改造成纯"待办+通讯录"工作台，或者产品化改造的时候。

很多人在群里问"能不能去掉"，心里想的是第一种，结果动手时按第三种去找方案，自然到处碰壁。所以第一步不是找代码，是先和业务方确认清楚：你要的是"看不见"，还是"不能用"，还是"这东西根本不该存在"？ 需求定级不同，后续方案和工期天差地别。

1.2 平台为什么默认要放这个按钮

理解这个问题之前，得先明白EOS这种低代码平台的移动端产品设计逻辑。开箱即用的移动门户，几乎必然包含三个核心入口：待办、已办、流程发起。产品团队在设计时有一个默认假设——移动办公应用就等于"待办审批 + 流程发起"，所以把"流程发起"作为标准能力直接渲染在首页底部。

这个假设对大多数通用OA场景成立，但对两类客户不成立：一类是流程起点在线下的单位，发起动作在生产现场、在业务窗口完成，手机端只需要处理审批；另一类是流程全部走业务系统封装的单位，用户必须从业务单据进入才能发起流程，直接发裸流程反而破坏业务数据的完整性。

换句话说，这个按钮不是bug，是产品设计取舍，所以平台不会提供一个叫"隐藏流程发起"的全局开关来让你一键搞定。它被当成了核心功能，而不是可插拔的附属功能。想去掉，就得从门户配置、权限体系或者前端定制三个方向里找突破口。

1.3 提出这个需求的高频场景

我实际接触过的案例里，提这个需求的大概分三类。

一类是员工规模不大、流程场景简单的单位。他们上移动端主要就是为了审批，真正发起流程的频率极低。那个"流程发起"按钮天天躺在底部，不仅没用，还容易被误触。误触之后生成空流程实例，过几天业务部门投诉"系统里多了好多脏数据"，最后责任全算到实施方头上。

一类是希望把所有流程入口收编到业务系统里的单位。报销、请假、用章这些流程，业务方已经做了专属模块，用户要发起得先进对应模块填业务单据，流程引擎在后台作为一个环节被调用。这种情况下，首页再放一个"流程发起"，用户就会绕过业务表单直接发起流程，导致单据数据缺失、审批意见对不上，实施方非常头疼。

还有一类是面向特定岗位的定制工作台。比如给车间班组长、仓库管理员做的手持终端页面，整个界面只留几个高频功能，底部本来就只该有"首页"和"我的"，结果平台默认渲染出来的"流程发起"按钮和整体界面格格不入。

不管哪种场景，下一步都要回答同一个问题：这个按钮到底是从哪来的。

2. 先判断底栏是谁画的：App原生壳还是H5门户页

2.1 快速判断两个来源的土办法

EOS 8.3.2的移动端，底部导航栏和首页入口按钮，可能存在于两个完全不同的载体里：一个是App原生壳，安卓工程或苹果工程里写死的底栏；一个是H5门户页，用手机浏览器也能直接访问的移动首页。

判断方法特别简单。拿手机浏览器直接访问你们移动门户的H5地址，如果底部同样能看到"流程发起"按钮，说明它是H5门户页渲染出来的，后续走门户配置或者改前端代码就行；如果浏览器里没有、只有App里有，说明它大概率画在原生壳上，要改的是原生工程。

还有一个辅助的土办法：在App里打开首页，滚动页面观察这个按钮。如果页面滚动时按钮跟着滚走了，那它是H5内容流的一部分；如果页面滚了半天它始终钉在底部，那多半是原生底栏。但这个办法不绝对，因为H5完全可以用固定定位做出同样效果，所以最靠谱的永远是浏览器对照法。

2.2 原生壳和H5门户的排查侧重点

确定来源之后，排查方向就不一样了。

如果是H5门户页，改动路径非常顺：后台配置能藏就藏，藏不了就改前端页面代码，改完刷新生效，最多让用户重进一次页面。排查时重点看门户首页组件的渲染逻辑、入口菜单配置、快捷入口配置这几块。

如果是原生壳，麻烦一些。你得拿到移动App的工程代码，在原生布局文件里找底部导航容器。安卓工程重点看布局目录下的底栏定义，iOS工程看标签栏控制器，跨平台框架的看公共导航组件文件。搜关键字不外乎"bottomTab""footerBar""mainTab"这类，结合全局搜"流程发起"的中文或拼音标识，定位按钮定义的位置。改完原生布局，还要重新构建App安装包，企业内部走应用商店分发的还得重新走发版流程。

这也能解释为什么同样一个问题，有人在群里说"后台配置一下就行"，有人说"要改代码重打包"——他们面对的压根不是同一个来源。

2.3 混合形态的识别

实际项目里还有一种混合形态，比上面两种都容易让人绕晕：底部导航栏是原生的，"流程发起"是其中一个原生图标，但点击后跳转的是H5的某个发起列表页。

这种形态下，你单纯去改H5页面没有用，因为按钮不属于H5；你以为是原生配置问题跑去找App开发，也可能一头雾水。正确的排查思路是：先在浏览器里确认H5页面本身有没有这个按钮，再确认App底栏上的按钮是固定定义还是动态从服务端拉的。有些App壳的底栏数据也是通过接口下发的，那本质上等于一个配置问题，只是入口在App的接口配置里，不在门户后台。

我建议所有排查都按这个顺序来：浏览器访问题H5地址 -> 观察App界面 -> 对比两个载体的差异点 -> 再决定动哪一层。按这个顺序排查，基本不会把时间浪费在错误的载体上。

3. 优先走配置路线：门户首页与导航栏的隐藏开关

3.1 后台门户配置的常规排查路径

确认按钮属于H5门户页之后，EOS 8.3.2大多数部署形态下，第一优先级的方案是去平台后台找门户配置。不要一上来就动代码。平台既然提供了门户能力，就必然配套管理入口，先把它找出来。

常规路径是：登录系统管理员账号，进后台管理功能，找名字里带"门户""移动""首页"字样的菜单。进入移动门户相关配置后，重点翻三类设置项。

第一类是首页栏目配置，控制首页显示哪些功能卡片或功能块。有的版本把"流程发起"做成了一个独立栏目，去掉勾选或者删除栏目，按钮就没了。

第二类是底部导航配置，控制底栏Tab的数量和排序。有的版本"流程发起"绑定在某个底部Tab上，需要去导航配置里把那个Tab删掉。

第三类是快捷入口配置，控制首页金刚区或快捷操作按钮。有的版本把流程发起做成了快捷按钮，跟"扫一扫""通讯录"之类摆在一起，这里也能单独移除。

我经手的部署案例里，三个版本三种情况都遇到过。所以别直接搜"流程发起"这四个字，容易找不到对应菜单，反而是在上面三类设置里挨个翻一遍，通常翻到第二类就能找到答案。

3.2 三类配置项怎么理解

这里把三类配置项的区别说得更细一点，方便你对照自己后台的实际界面。

首页栏目配置通常是组件化的，每个栏目对应页面上的一个区块。你看到"工作台""我的待办""我的已办""流程发起"这些栏目卡片排成一列，就是它。这种配置的显示逻辑一般是"配置了才渲染"，把流程发起栏目移除后，整个区块连带按钮一起消失，改动最干净。

底部导航配置管的是底栏那几个Tab。EOS移动端常见的底栏有"首页""待办""我的"，也可能把流程发起作为其中一个Tab，甚至放在中间做突出按钮样式。这种配置项通常是数组结构，每个Tab有标题、图标、跳转地址，删掉对应那一项即可。

快捷入口配置类似九宫格或金刚区，属于首页栏目里的一个子模块。流程发起如果在这里，通常还有一堆其他快捷入口陪着它。单独摘掉它不会影响其他入口，但要注意有些版本里这里的数据来源是流程分类列表，而不是静态按钮配置，得去流程分类的展示设置里控制。

3.3 配置生效条件与验证方法

改完配置，别急着下结论。这类配置通常不是保存即生效那么简单，中间往往隔着一层缓存。

常见的生效逻辑是：后台保存配置 -> 触发移动门户配置刷新或定时同步 -> 前端页面重新拉取配置 -> 界面变化。我自己遇到过远程改完栏目配置，手机端刷新三次还是老样子，后来发现平台有"移动端配置缓存"的刷新入口，有的版本叫"清理门户缓存"，有的叫"重新发布移动端"，点一下才同步到前端。

这里给个实操建议：改完配置后，先在后台找有没有"发布""同步""刷新缓存"之类的按钮，点完再去看手机端。如果没有这类按钮，就等一两分钟，同时确认App里的H5页面有没有触发配置重新加载——有些App壳只在启动时拉一次配置，之后一直用内存里的副本，需要杀掉App进程再重进。

验证时还要注意一个细节：用一个业务账号登录看效果，别拿管理员账号。管理员账号的可见性规则跟普通用户不同，容易出现"管理员看着没了、普通用户看着还在"的假象。这一点在下一章的权限方案里还会遇到。

4. 权限管控路线：让指定角色看不到流程发起

4.1 菜单权限和流程可见权限是两个层面

配置路线走不通，或者业务方要求的是"只有少数角色能发起流程，其他角色一律不显示"，那就切到权限管控路线。

这里要区分两个层面。一是菜单/功能权限。平台管理后台里，移动门户首页的各个功能项通常对应着权限资源。把"流程发起"这个菜单从角色的权限树上摘掉，该角色登录后首页就不该渲染这个入口。

二是流程可见权限。就算"流程发起"按钮还在，点进去能列出的流程本身也是受权限控制的。把某类流程的可见范围收窄，用户点进去看到的是空列表，效果上约等于没有发起入口，但体验上有点怪。

实操中最稳的做法是两层一起做：首页按钮层用菜单权限控制，发起列表层用流程可见权限控制。只控制一层会出问题——按钮还在但列表为空，页面很怪异；按钮没了但列表还能通过URL直接访问，又没达到"不能用"的目的。

4.2 多入口情况下怎么配齐

权限方案一个特别容易翻车的点是："流程发起"在移动端往往不止一个入口。

我见过不少移动门户里，"流程发起"至少出现在四个位置：首页底部导航栏、首页九宫格快捷入口、工作台页面的应用列表、搜索功能的直达结果。这还不算流程模块内部自己的发起按钮。

你以为权限配置只配一处就行，结果用户换个入口照样发起。所以动手之前，先把移动端所有能触达"流程发起"的入口全部列出来，逐个确认它们背后的权限资源是不是同一份。如果是同一份，一次配置全生效；如果是多份，必须逐一对齐。这个清单最好在项目初期就维护起来，后续不管是配置还是定制都有据可查。

4.3 权限隐藏的边界与副作用

权限方案最大的好处是不用改代码、不碰构建产物、版本升级不冲突，但副作用也明显。

第一，权限树本身可能很复杂。平台的权限体系里往往同时有角色、用户组、岗位等多套维度。你给某个角色摘了"流程发起"，但角色之间如果有继承关系，或者用户挂在多个用户组下，很容易出现漏网之鱼。我见过一个单位，权限配好了，业务部门报"还有一半人能看到"，查了半天是用户挂在一个继承自公共角色的用户组下。

第二，页面渲染逻辑差异。有些页面的逻辑是"没权限就不渲染"，有些是"没权限也渲染但点击报错"。后一种用户看到的是"按钮还在但点不动"，体验很差，容易被误判成系统故障。所以改完权限，一定要用无权限账号走一遍完整点击路径，确认按钮是真消失还是假显示。

第三，管理员验证陷阱。前面提过，管理员账号的权限模型跟普通用户完全不同，管理员页面上看到的权限变化，不一定能代表业务用户。改完权限后，至少找三个账号过一遍：管理员、目标角色用户、无关角色用户。三个账号的差异能很快暴露出权限配置的错位。

5. 最终兜底：前端二次开发做条件渲染

5.1 定位"流程发起"按钮的源码位置

后台配置和权限方案都试过，仍无法满足，或者需求本身就是"帮甲方定制一套干净的移动端界面"，那就得动前端工程了。

EOS 8.3.2的移动H5门户，一般以独立的微前端资源包或门户工程形式存在。拿到工程之后，第一件事是在代码里定位按钮。搜索关键字不用多，两个就够：中文"流程发起"和它的英文标识。平台源码里通常有语言配置文件，中文文案对应的key值就是按钮代码层的关键字，顺着key反查组件最方便。

举个例子，语言文件里如果写着：

javascript复制{
  "home.startProcess": "流程发起"
}

全局搜索"startProcess"就能定位到首页组件里渲染这个按钮的位置，常见于首页入口菜单组件、底部导航组件、工作台快捷操作区。翻到代码后，先看它跟父组件的数据流：按钮是写死渲染的，还是根据某个配置数组循环出来的。如果是循环渲染的，大概率在配置数组里加一个过滤条件就能藏掉，属于最幸福的场景。

5.2 加配置开关还是直接删组件

定位到组件之后，改法上有两个选择，我强烈建议优先加开关，而不是直接删。

直接删的好处是干净利落，几行代码的事。但代价很实在：平台以后升级时，改动点可能跟官方代码冲突；甲方哪天反悔想要回这个按钮，又得改代码重新发版，来回折腾。

加配置开关的做法是，在渲染出口加一个条件判断，从系统参数里读开关：

javascript复制// 读取系统参数：是否显示流程发起按钮，默认显示
const showStartProcess = getSystemParam('mobile.portal.showStartProcess', 'true');

// 在需要渲染按钮的位置增加条件判断
if (showStartProcess === 'true') {
  renderStartProcessButton();
}

这样需求变化时后台改参数就行，不用动代码。这个模式我建议推广到所有"平台默认功能是否展示"类的定制上——凡是给甲方做移动端定制，默认按钮都做成本地配置项控制，而不是写死显隐。你省下来的是后续每一次需求变更的发版成本，非常值。

5.3 构建与部署的实测要点

前端改完不是结束，构建和部署这两步才是真正容易卡壳的地方。

第一步，确认H5门户的部署形态。如果移动端H5是独立部署的前端工程，构建产物推到对应Web目录即可，关键是要让App加载到新资源。常见办法是给静态资源加版本号或者用带hash的文件名，避免App壳缓存旧资源。

如果产物被做成了App内置的"离线资源包"，那就要把新资源包打进App工程重新构建，用户端需要升级新安装包才能看到变化。这一点必须提前写进发版计划，否则你上线三天，群里全是"怎么还是老样子"的反馈。

第二步，回归测试。别只看按钮消失就算完。重点回归三块：首页其他功能是否受影响，比如删按钮时有没有误伤同模块的其他入口；直接通过URL访问流程发起页是否还能打开，如果业务上要堵死，后端页面访问权限必须同步收紧；不同角色下的渲染结果，管理员、普通用户、无权限用户各看一遍。

6. 实测记录：改完之后的常见翻车现场

6.1 老客户端缓存导致"明明改了还显示"

这条是实际项目里出现频率最高的一坑，单独拎出来说。

有一次帮客户做完配置隐藏，后台确认权限都对，前端也验过，结果过了半天业务部门还是说"按钮还在"。带着工程师现场排查，发现用户手机上的App是三个月前的旧版本，内置离线资源包还是老代码，服务端的新配置它压根没拉取。那个版本App的启动加载策略是"先本地资源包、后增量更新"，本地包不更新，界面永远是老的。

解法不在服务端，在客户端的更新机制。要么推动用户升级App，要么在H5页面层做资源版本检测，发现版本落后强制刷新。用户数几百人的单位，让用户重装或升级也够用；几千人在线的场景，建议从发布规范上堵住：每次改移动端界面，都要把"客户端版本兼容要求"写进发布说明，别默认所有人都在用最新版。

6.2 权限配置只配了半边，自己正常别人翻车

另一个高频翻车点来自验证账号选错。

权限管控路线最怕的就是全程拿管理员账号验证。管理员的权限模型跟业务用户完全不同，管理员看不到不代表业务用户看不到。反过来也有：给某个角色摘权限时，配在了用户组的上级角色上，但下级角色渲染时优先读取自己的权限副本，用户组下的人照样能看见。

我现在的习惯是：改完权限后，至少找三个账号过一遍。管理员、目标角色用户、完全无关角色用户，三个账号的界面差异能很快暴露权限配置的错位。同时记得把流程发起的多个入口都过一遍，很多版本里首页入口和流程中心入口是两套权限资源，只配一处必然翻车。

6.3 只藏按钮不等于堵住入口，别把账算错了

最后提醒一句，UI层面的隐藏永远不等于功能层面的禁用，这在EOS移动端同样成立。

把按钮隐藏或删掉，只是让用户在正常点击路径上看不到入口。如果流程发起页的URL是固定可猜测的（比如路由就是 /flow/start 这类），用户完全可以在浏览器里直接敲地址访问。移动端页面路由是明文的，截图发给同事，人人都能进去。

所以，凡是业务上真正确认"发起操作对某些角色不可用"的，一定要回到平台权限体系里，把流程发起的访问权限一并收掉。界面隐藏解决的是体验问题，权限禁用解决的才是管控问题，这两件事别指望用一个动作搞定。

6.4 版本回退预案

最后补一个经验，改前端方案时一定留好回退路径。

做移动端定制不像改后端服务，出问题可以立刻重启回滚。H5资源包一旦被App缓存下来，就算你马上恢复旧资源，用户端也可能继续用着出问题的版本。所以我在改这类功能时，习惯把改动文件单独放一个目录，和工程其他改动隔离。一旦现场反馈异常，直接把定制目录摘掉，重新构建一份干净的资源包，配合强制刷新快速回退。

另外，定制和官方升级包的合并顺序也要注意。平台发新补丁后，如果你当时的改动是直接改官方源码，合并时大概率冲突；如果是独立配置开关加外围条件渲染，官方源码升级基本不动你的定制逻辑，合并成本低很多。这也是我坚持"加开关不删组件"的原因之一——改得越少，以后越省心。

如果你要的其实是把整个底部导航栏都换掉，那是移动端整体改造层面的事，建议走应用工程里全局导航组件的定制，别在门户首页里零敲碎打。导航栏在App壳里通常只有一个地方定义，改全局组件一次到位，维护成本最低。真走到那一步，再回来看看这篇排查思路，你会发现前面判断H5与原生来源的那套方法，照样能复用。