直接说结论：能去，而且不需要动业务代码，甚至不需要重新发版。EOS 8.3.2 移动端底部那个“流程发起”按钮，十有八九不是你们业务系统画的，而是微前端框架或者移动端壳子自带的快捷入口。这种坑我踩过好几次，今天把排查思路和几种可行的处理方式一次性说清楚，顺便附上我在实际项目里验证过的操作步骤。如果你是第一次碰 EOS 移动端定制，别慌，跟着下面的思路走，10 分钟内就能定位到修改点。
1. 动手之前，先搞清楚这个按钮是哪一层渲染出来的
很多人一上来就全局搜“流程发起”四个字，搜不到就开始怀疑是不是平台写死了。其实在 EOS 8.3.2 这种基于微前端 + 容器化的移动端架构里，底部按钮通常有三种来源，思路错了后面全白费。
来源一：业务 H5 页面自身的底部组件。这种最好办，打开你们自己的前端工程，搜索“流程发起”或“发起”关键字，基本能找到对应组件或路由配置。如果能搜到，说明是业务代码控制的，直接改页面就行。
来源二：EOS 容器/壳子注入的原生 TabBar。这种最隐蔽。EOS 移动端在加载业务页面时，会根据应用配置或租户配置，在 WebView 外壳层注入一个底部导航栏。“流程发起”和“待办”“已办”“我的”并列，看起来像个普通 Tab，但其实它不在你们前端工程里，而是平台容器动态拼接的。
来源三：微前端基座（如 qiankun、无界等）的公共布局组件。EOS 很多定制版会套一层微前端基座，公共底部就挂在基座里。此时“流程发起”可能是一个自定义菜单项，由平台配置文件或启动参数决定。
怎么快速判断是哪种？教大家一个土办法：用 H5 调试工具（vConsole 或者 Chrome DevTools 远程调试），点击那个“流程发起”按钮，看 DOM 结构。
- 如果按钮所在 DOM 的 id 或 class 前缀带
eos-、app-layout、native-tab之类，大概率是容器或基座注入的。 - 如果
class是你们自己项目打包出来的 hash 类名，那就在业务代码里。 - 还有一种更直接的：在按钮上右键选择“检查”，沿 DOM 树往上找 parent，看到
#root或#app之外还有内容，那就不是你们前端应用中的东西。
我在某项目里遇到过一种情况：业务页面用的是 Vue 3，路由切换时底部按钮还在，说明它根本不在路由组件里，而是被后挂载到 body 下的独立组件，这种就是壳子注入的铁证。
定位到层级之后，再去决定怎么处理。别急着改代码，EOS 8.3.2 的移动端定制很多时候有现成的配置项，改配置比改代码稳得多，升级也不怕被覆盖。
2. 业内主流的几种处理路径，以及我推荐的优先级
确定按钮来自哪一层后，处理方式无非三种：配置关闭、样式隐藏、代码改造。但优先级一定要排对，否则后面升级平台版本时很可能白改。
路径一：平台配置项开关（优先级最高）
EOS 8.3.2 的移动端应用在发布时，一般会在应用配置中心或者移动端设置里有“是否显示快捷发起”“显示发起按钮”之类的开关。有的版本藏在“应用配置 - 功能配置 - 移动端”，有的版本藏在“流程中心 - 发起配置”。如果你用的是标准发行版，优先找这个开关。
- 优点：改动最小，升级平台版本不会失效。
- 缺点：有些版本这个开关只对原生 App 生效，H5 端不生效。
路径二：全局 CSS 劫持隐藏（优先级中等）
如果平台没有提供开关，或者开关控制不了 H5 页面，最稳妥的隐藏方案是写一段全局样式，通过统一选择器把按钮隐藏掉。比如在入口 HTML 或公共样式文件里加：
/* 以按钮常见类名为例，实际以你项目里 DOM 的类为准 */ .eos-process-launch, .launch-flow-btn, [data-role="launchProcess"] { display: none !important; }这段代码的目的是让容器注入的按钮不再显示，但这属于“纸面隐藏”，按钮事件绑定可能还在，但视觉上已消失。业务上一般没问题，因为用户也看不见且点不到。但后续平台升级如果改了类名，就需要同步调整。
路径三：修改容器/基座源码或路由拦截（优先级最低）
如果你们用的是深度定制的 EOS，比如在开源版上做了二次开发，那可以直接改容器或者基座的布局组件，把“流程发起”按钮从数据源里移除。这一般要找平台源码里的layout或context-menu配置，不是 JS 项目的话还要看 Java 服务端下发的配置 JSON。
之所以放最后，是因为这种方式对团队能力和后期维护要求最高。除非真的有配置和样式都搞不定的场景，否则不建议一上来就动源码。
我碰到过一个项目，最初通过 CSS 隐藏了按钮，但后来某个版本升级后平台把按钮的渲染位置移出了业务页面 DOM，那一把隐藏代码直接失效，用户又在底部看到“流程发起”，而且四个 Tab 挤在一起很难看。最后查出来是平台的一个版本更新改了 TabBar 的渲染逻辑，加了新的容器层。教训就是：用 CSS 隐藏时一定要把选择器写得足够“狠”，尽量加上父级容器限制，避免误伤别的元素。
3. 实操验证：用配置开关和全局样式两步走，稳妥去掉底部按钮
接下来给一份可以直接照搬的实操流程。我以一个中等复杂的 EOS 8.3.2 移动端 H5 应用为例，假设场景是：客户觉得“流程发起”功能冗余，要求隐藏，但“待办”“已办”等 Tab 保留。
3.1 第一步：检查应用配置中心
登录 EOS 管理后台，找到“移动端应用”或“应用配置”菜单。看看有没有“快捷入口”“发起按钮”“自定义 TabBar”之类字段。
以常见的二开版本为例，路径大致是：流程中心 -> 移动端设置 -> 功能显示。确认这几个开关：
显示发起按钮：关掉允许自定义首页底部菜单：开启移动端快捷入口启用标记：关闭
截图我就不放了，不同版本菜单位置会有差异，但关键字基本一致。操作完之后注意要点“发布”或者“同步到正式”，否则配置只对测试环境生效。
如果一个开关都没找到，别继续找了，直接进入第二步。
3.2 第二步：在入口 HTML 中注入全局隐藏样式
打开你们 H5 项目的入口文件，比如index.html，在<head>里加一段全局样式。下面是实际项目的写法：
<style> /* ========== 隐藏 EOS 容器注入的底部“流程发起”按钮 ========== */ /* 优先根据 DOM id 隐藏 */ #tab-launch, #launch-process, /* 如果上述 id 没命中，换 class 策略 */ .bottom-bar .launch, .tabbar-item[data-code="launch"] { display: none !important; pointer-events: none !important; } </style>这段代码我测试下来有几个好处：
- 不在任何业务组件里写死，即使平台升级导致按钮 DOM 位置变动，只要 id 或
>// 在子应用入口文件 main.js 中添加动态样式覆盖 const style = document.createElement('style'); style.textContent = ` #tab-launch { display: none !important; } `; document.head.appendChild(style);注意：这段代码要在子应用挂载执行的早期运行，否则可能闪烁一下才消失。但这属于临时方案，长期还是建议走配置或基座改造。
4. 常见问题与排查技巧实录
这个需求本身不难，但很多人会卡在“按钮看不见了但功能受影响”“配置明明改了却不生效”等细节上。我把实操中高频出现的问题整理一下。
4.1 隐藏按钮之后，原有的流程发起入口也找不到了
很多人只关注底部按钮本身，忽略了一个前置问题：平台可能会把“发起”功能做的非常集中。如果你把快捷入口关了，而业务页面又没有一个合理的入口，用户体验会更差。
建议隐藏前先梳理一下平台还有哪些“发起”入口：
- 首页轮播图点进去的快捷入口
- 消息中心收到的“待办详情”里的“处理”
- 流程中心列表页右上角的“+”按钮
- 全局搜索后附带的“发起”功能
只要这些入口在，去掉底部“流程发起”基本无感。如果发现其它入口都被平台规划到了同一个控制开关下，那你要权衡一下：到底是去掉底部按钮更重要，还是保留所有入口更重要。
4.2 配置中心和样式都改了，但 App 端依然显示旧界面
这种多半是缓存问题。EOS 8.3.2 的移动端 App 或 H5 页面一般会做静态资源缓存，样式和配置更新后不是即时全量生效。
处理办法按顺序尝试：
- 在 H5 页面入口 URL 后面手动加
?v=时间戳强制刷新 - 后端缓存清理（如果是 Java 服务端，重启相关缓存服务）
- App 端杀掉进程重新打开，或者清缓存
- 确认你们发布是否有灰度逻辑，测试环境和正式环境不要弄混
4.3 隐藏按钮后底部 Tab 布局变挤或出现空白
EOS 底部导航如果不是动态等分布局，隐藏“流程发起”后，剩余 Tab 不会自动补位。这时需要额外处理剩余 Tab 的宽度，或者接受一个居中 Tab 样式。
处理方式：
- 如果是平台自带 CSS，看剩余 Tab 是否用了
flex: 1等分，如果是，一般能自动拉平 - 如果固定宽度，建议不要强行改宽度，而是把某个业务 Tab 显示文本加长，或者把底部 Tab 总数控制在 3~4 个
- 实在不行，在 CSS 里给
.bottom-bar加justify-content: space-around，让剩余 Tab 均匀分布
4.4 隐藏后调试工具里还能看到按钮 DOM，但页面不显示
这是正常的。DOM 还在，但被
display: none隐藏了，事件绑定也仍然存在。有些人会担心这会不会有安全隐患。实际上，只要用户看不到也点不到，就没有任何风险。如果还有强迫症要求 DOM 完全不渲染，那就只能走代码改造路线，把渲染数据源里的“流程发起”项移除。4.5 平台升级后按钮又冒出来
这是最气的。平台升级、补丁更新，或者二开包的某些版本更新，都会导致项目里的样式代码失效。
防患措施：
- 把隐藏代码收敛到一个专门的文件里，比如
hide-launch-button.css，并在代码注释中写明要同步检查的配置位置。 - 升级前先对比平台发的变更说明，关注“移动端导航”“TabBar”“快捷入口”关键词。
- 如果你们有自动化测试，加一条用例：进入首页后断言“流程发起”文字不存在。
我在项目里就吃过升级亏。某次平台从 8.3.2 升到 8.3.4，底部按钮由原生 TabBar 改成了自定义 H5 组件，那部分原生托管的样式就全失效了。幸好只影响这一个按钮，重新调整一下选择器就好。但如果你们的升级频繁，还是建议推动平台侧把“流程发起”做成可配置项，这样以后都不用再动代码。
5. 这类定制的边界与影响范围：值得多想一步
很多人把这个问题当成一个“改配置、加样式”的小活，但我建议多花几分钟考虑边界。毕竟它不是一个孤立的小改动，处理不好会影响整个移动端的工具体验，甚至牵连到流程审批的日常工作。
5.1 去掉了底部“流程发起”，意味着什么
第一层意义是界面精简。底部四个 Tab 变三个，或变成居中按钮，视觉上更聚焦。
第二层意义是改变了操作路径。原本用户打开 App 就能发起流程，现在必须先进“工作台”或“全部应用”，多一步操作。对于高频发起业务的人员来说，这个操作变化值得重视。
第三层意义是权限收敛。个别情况下，客户是希望普通用户不要随意发起流程，只允许看到自己的待办和已办。这时隐藏“流程发起”不仅是为了界面美观，本质上是把入口收走，让用户无法触发某些流程。如果真有这个需求，记得只做界面隐藏是不够的，还要在后端接口权限上做限制，否则用户直接输入 URL 或绕过按钮依然可以发起。
另外，这个按钮去掉了，如果后续又想加回来，不用重新开发，把配置改回来即可。所以哪怕你现在不确定要不要去掉，也可以先按隐藏的方式做，留好回退空间。
5.2 只去掉“流程发起”，其他 Tab 的取舍逻辑要一起想清楚
实际操作中，往往不是单独去掉“流程发起”这么简单。客户的想法通常是：“底部太乱了，能不能把流程发起去掉，顺便把某某入口也统一一下。”
我的建议是：每次改动底部导航，都把它当成一次信息架构梳理。列一张表，把你当前底部所有入口列出来，逐个标注“必须常驻”“低频使用”“可转移到二级页面”。然后再决定哪些删除、哪些留下。
比如我之前处理过一个客户：
- 原始底部：待办、已办、流程发起、我的
- 调整后：待办、工作台、我的
- “流程发起”变成了工作台里的一个常用卡片
这样做的核心逻辑是：把“发起流程”从全局导航降级为工作台内部模块，保留功能，但不占用底部空间。效果是让底部只有三个一级入口，信息层级更清晰，用户的注意力能更快落到待办和工作台上。
5.3 影响范围评估清单
无论你是开发人员还是实施顾问，做完这种改动后，至少要检查以下影响点：
- 流程发起权限是否受影响（特别是隐藏按钮后，用户还能否走完流程发起链路）
- 移动端数据统计中的入口点击量（若平台有埋点，隐藏后的点击流失是否被其他入口补充）
- 测试用例是否需要调整（自动化和手工用例中涉及“流程发起”的部分）
- 嵌入式场景如企业微信、钉钉里的 H5 微应用，是否也共用了这套底部配置
我在某项目中就遇到过：客户在 App 里去掉了“流程发起”，但企业微信里的 EOS 微应用还在用同一套 H5 页面，里面的底部按钮也自然消失了。客户当时觉得没问题，结果第二天就有人反馈说在企微里找不到发起入口。后来在这个场景下我再处理类似需求，都会先问清楚：你们有哪几类端在跑？是只改 App 端还是所有端都要统一？
补充一句：移动端和桌面端不要一块动。桌面上的流程中心布局和移动端完全不一样，“流程发起”在桌面端很可能是一个合法且高频的入口，只在移动端隐藏即可。改动前一定要确认应用的市场覆盖情况，避免“隐藏完了、找不到入口”这种低级失误。
6. 写在最后：一个小技巧，建议直接收藏
如果你不想动代码，又找不到平台配置开关，还有一个很取巧的办法：在 EOS 移动端管理后台看有没有“自定义菜单”这类功能，部分版本允许你重新编排底部 Tab，直接把“流程发起”从列表里删掉就行。这比写 CSS 再升级后失效要稳得多。
万一你所在版本找不到这个功能，那就按本文第二章节的方式处理，优先全局样式，把选择器写好，升级后多留意平台更新说明就好。
我自己的习惯是：每次改动完成后，在项目文档里记一笔“本次隐藏方案、选择的逻辑依据、升级后需重新验证的事项”。下次升级出了问题，翻记录就能直接定位，不用从头排查。EOS 这种会频繁迭代升级的平台，文档这块一定要跟上，不然每升级一次就得重新折腾一轮。
去掉底部“流程发起”这个需求本身不复杂，真正花时间的往往是定位它到底是谁渲染的、以及如何善后。希望这篇实操记录能帮你少走点弯路，动手前先判断来源，动手时优先配置，动手后记得验证全端效果。
