企业官网建设流程全解析

分享能力这块，在鸿蒙应用开发里属于那种"平时想不起来、真要做又绕不开"的模块。我最早接触ShareExtensionAbility是在一个内容聚合类的项目里，当时的需求很朴素：用户在应用里看到一篇不错的图文，点一下分享，能直接拉起系统分享面板，把标题、摘要、缩略图一起带出去，落到备忘录、邮件或者聊天工具里。听起来简单，但真动手才发现，分享模板服务扩展能力跟普通的页面跳转完全是两套逻辑——它不是一个你能随便router.pushUrl过去的页面，而是一个由系统在特定时机拉起、生命周期由系统托管的扩展组件。

@ohos.app.ability.ShareExtensionAbility这个能力，本质上是给应用提供一个"被分享"的入口。别的应用或者系统分享面板在需要处理分享内容时，会通过配置好的意图去匹配到你的扩展，然后系统负责把扩展拉起来，你在扩展里拿到分享数据、做二次加工、再决定往哪儿送。它解决的核心问题是：让一个应用能够以标准化的方式接收外部传入的分享内容，而不需要用户手动复制粘贴。适合谁来参考？我觉得两类人最需要：一类是正在做内容类、工具类应用、需要把"分享进来"做成闭环的开发者；另一类是已经会用UIAbility、但对扩展能力体系还没摸透、想搞清楚"扩展到底和普通 Ability 差在哪"的中级开发者。

下面我按自己踩过的顺序，把这个能力的里里外外拆开讲。不讲空话，重点放在配置怎么写、数据怎么接、生命周期怎么走、以及那些文档里不会明说但实际会绊你一脚的细节。

1. 先搞清楚 ShareExtensionAbility 到底站在哪条链路上

很多人第一次看这个能力，会下意识把它当成"我要分享出去"的出口。这是个典型的方向性误解，必须先掰正，否则后面配置全错。

1.1 它是接收方，不是发起方

ShareExtensionAbility扮演的是分享接收端的角色。当用户在某个应用里触发分享动作，系统会弹出分享面板，面板里列出的"可以接收这份内容的应用"中，如果你的应用配置了对应的分享扩展并且匹配上了数据类型，你的扩展就会被系统拉起。也就是说，数据是从别人那儿流向你的，你在扩展里做的是"接住这份数据然后处理"。

那"我要把内容分享出去"怎么办？那是发起方的事，通常用系统提供的分享接口去拉起分享面板，把数据打包丢出去，跟你写不写ShareExtensionAbility没关系。这两件事经常被混为一谈，我在早期项目里就见过有人为了"实现分享功能"去配了一堆扩展，结果发现方向反了，白折腾。

所以定位要清晰：这个能力是让你的应用成为分享的落点。典型场景比如——你的应用是个笔记工具，用户从浏览器分享一段文字过来，你的扩展接住后存进笔记；你的应用是个图片处理工具，用户从相册分享一张图过来，扩展接住后进入编辑流程。这些都是"接收"的典型用法。

1.2 扩展能力和普通 UIAbility 的本质差异

理解差异是写好扩展的前提。普通UIAbility是你自己说了算：什么时候启动、启动后显示什么页面、生命周期怎么流转，基本都在你的掌控里。而扩展能力是系统托管的——系统决定何时拉起它、给它什么数据、什么时候销毁它。你没法像启动普通页面那样主动去startAbility一个分享扩展，它只会在系统认为合适的时机被唤醒。

这个差异带来几个直接影响。第一，扩展里不能假设自己有独立的、长期存在的界面栈，它更像一个"临时工位"，干完活就走。第二，扩展的生命周期回调触发时机和你熟悉的onCreate/onForeground不完全一样，得按扩展的规矩来。第三，扩展里拿到的分享数据是通过意图参数传进来的，你得在合适的回调里解析，而不是自己主动去某个地方取。

我习惯用一个类比：普通UIAbility像是你自己开的店，什么时候开门营业你定；扩展能力像是商场里的一个服务窗口，商场（系统）通知你"有客人来了"你才上岗，客人办完事你就撤，窗口本身不归你长期占用。想通这一点，后面很多设计取舍就顺了。

1.3 一次完整的分享接收链路长什么样

把链路走一遍，心里才有全局。假设用户在某应用里选中一段文本点了分享：

1. 发起方应用调用系统分享接口，把文本内容和类型（比如纯文本）打包。
2. 系统弹出分享面板，根据内容类型去匹配所有声明了能接收该类型的应用扩展。
3. 匹配到你的ShareExtensionAbility后，系统拉起你的扩展，把分享数据通过意图参数传进来。
4. 你的扩展在生命周期回调里解析数据，做业务处理（存储、预览、转交主应用等）。
5. 处理完成后，扩展按规范结束自己，控制权交回系统。

这条链路里，你能控制的只有第 4 步和第 5 步。第 1 到 3 步是发起方和系统的事。所以写扩展的核心工作，就是把第 4 步做扎实、第 5 步做干净。链路清楚了，接下来就是配置——这是最容易出错、也最容易被忽略的地方。

2. 模块配置：分享扩展能不能被拉起，八成看这里

扩展能不能被系统匹配到，几乎完全取决于配置文件写得对不对。我见过太多"代码没问题但就是不触发"的案例，最后都栽在配置上。这一章把配置拆细。

2.1 module.json5 里扩展能力的声明结构

分享扩展需要在模块的配置文件里声明为一个extensionAbilities条目。核心字段包括名称、入口代码路径、类型、以及最关键的skills意图匹配规则。结构大致如下：

{ "module": { "extensionAbilities": [ { "name": "ShareExtAbility", "srcEntry": "./ets/shareext/ShareExtAbility.ets", "type": "share", "exported": true, "skills": [ { "actions": ["ohos.want.action.sendData"], "uris": [ { "type": "text/plain" } ] } ] } ] } }

几个字段逐个说清楚。type必须是share，这是告诉系统"我是一个分享类型的扩展"，写错了系统根本不会把它当分享接收端。exported要为true，因为拉起你的是别的应用或系统，属于跨应用访问，不导出就没法被外部唤起。srcEntry指向扩展的实现文件，路径要对得上，大小写敏感这点在部分环境下会坑人。

skills是整个配置的灵魂。actions里声明你能响应的动作，分享场景通常是ohos.want.action.sendData。uris里的type声明你能接收的数据类型，比如text/plain表示纯文本、image/*表示任意图片。系统就是拿发起方的内容类型去和这里的声明做匹配，匹配上了才会把你的扩展列进候选。

2.2 意图匹配为什么总是不生效

这是最高频的问题。表现是：代码写好了、扩展也声明了，但分享面板里就是不出现你的应用。排查下来，原因集中在几类。

第一类是type写得太窄或太宽。写太窄，比如只声明了text/plain，但发起方分享的是text/html，那就匹配不上。写太宽，比如直接*/*，虽然能匹配很多，但有些系统版本对过于宽泛的声明会有额外限制，反而不稳。我的经验是按实际业务需要精确声明，需要多种类型就列多条，别图省事一把梭。

第二类是actions漏了或拼错。ohos.want.action.sendData这个字符串一个字母都不能错，我见过把sendData写成senddata的，大小写一错，静默失效，连报错都没有，排查起来极其费劲。

第三类是exported忘了设true。默认值在不同配置下可能不是你想要的，跨应用唤起必须显式导出。这个坑很隐蔽，因为本地调试时如果恰好有同应用内的调用路径，可能表现正常，一换到真实跨应用场景就哑火。

提示：改完配置后一定要重新安装应用，光热重载有时不会让系统重新读取扩展声明，导致你以为配置没生效，其实是旧配置还在跑。

2.3 多类型接收的声明策略

实际业务里，一个分享扩展往往要接多种内容：文本、图片、甚至文件。这时候uris数组可以放多条，每条声明一个类型。但要注意，声明得多不等于处理得好。系统把数据丢给你之后，你得在代码里根据实际类型分流处理，声明只是"敲门砖"，真正的兼容性靠代码兜底。

我一般的做法是：配置里把业务确实支持的几种类型列全，代码里用一个统一的类型判断入口，按type分派到不同的处理分支。这样配置和代码是对齐的，不会出现"声明了能接图片但代码里根本没处理图片分支"的尴尬。另外，如果某类内容你只是勉强能接、处理体验很差，宁可不声明，也别为了面板里多出现一个入口而牺牲体验——用户点进来发现处理不了，比压根不出现更伤。

3. 扩展的生命周期：在系统给的窗口里把活干完

扩展被拉起后，生命周期回调是你唯一的落脚点。这块和普通 Ability 有相似也有不同，得单独拎出来讲。

3.1 onCreate 里该做什么、不该做什么

onCreate是扩展被创建时的第一个回调，适合做轻量的初始化：解析传入的意图参数、准备必要的数据结构。但绝对不要在这里做耗时操作，比如大文件读写、网络请求。原因很简单：扩展是系统临时拉起的，用户对"点分享后多久有反应"非常敏感，onCreate里卡住会直接表现为分享面板响应迟钝甚至无响应，体验极差。

我的习惯是把onCreate压缩到只做三件事：拿到want参数、把分享数据提取出来放到成员变量、标记一个"已就绪"状态。真正的业务处理放到后续回调或者异步任务里。这样扩展能快速完成创建、尽快给用户反馈。

3.2 分享数据的解析入口

分享数据是通过意图参数传进来的，通常在want里。文本类内容一般在参数的某个字段里，URI 类内容则是一个指向资源的地址。解析时要注意两点：一是判空，不是每次分享都带全字段，发起方可能只给了文本没给标题，代码里必须对每个字段做存在性判断；二是类型校验，别假设传进来的就是你期望的类型，拿到后先确认再处理。

举个我实际写过的处理逻辑：先从参数里取文本内容，取不到再尝试取 URI，两者都没有就当作无效分享，直接给个轻量提示然后结束扩展。这个"降级链"很重要，因为不同发起方给的数据完整度差别很大，硬编码只认一种格式，兼容性会很差。

3.3 处理完成后如何干净地退出

扩展干完活要主动结束自己，把控制权交回系统。这一步做不干净，轻则残留后台、重则影响下次唤起。结束的时机要把握好：业务处理完成、用户已经得到明确结果之后再结束，别在处理中途就撤，否则用户看到的是"点了没反应"。

还有一个细节：如果扩展里弹了确认框或者预览界面，要确保用户操作完之后才走结束流程，而不是弹框的同时就把扩展销毁了。我早期就犯过这个错，弹了个"已保存"的提示，结果扩展立刻结束，提示一闪而过，用户根本没看清。后来改成提示展示足够时间、或者等用户确认后再结束，体验才正常。

4. 数据接住之后往哪儿送：三种典型落地方式

扩展把数据接住了，接下来是业务问题：这份数据怎么用？根据应用形态不同，落地方式差别很大。这一章讲三种我实践过的模式。

4.1 直接落库：适合轻量内容

如果分享进来的是短文本、链接这类轻量内容，最直接的方式是在扩展里完成存储，然后结束。比如笔记类应用，用户分享一段文字进来，扩展解析后直接写进本地数据库，给个"已保存"的反馈就完事。这种方式链路短、响应快，用户感知也好。

但要注意，扩展里做存储要控制好数据量和耗时。写一条短文本没问题，如果要写大量数据或者做复杂的事务，就得考虑异步处理，别阻塞扩展的主流程。另外存储的权限和路径要提前确认好，扩展运行的环境和主应用不完全一样，路径假设错了会写失败。

4.2 转交主应用：适合需要完整界面的场景

如果分享进来的内容需要用户在一个完整界面里继续操作——比如图片编辑、长文排版——那扩展本身不适合承载这些重界面。更合理的做法是：扩展接住数据后，把数据转交给主应用的某个页面，由主应用来完成后续的复杂交互。

转交的关键是数据怎么传。可以直接把内容塞进启动参数里带过去，但内容大了就不合适；更稳妥的是先把数据落到一个临时位置，把地址传给主应用，主应用再去取。这里要注意临时数据的清理，别转交完就忘了，日积月累会占空间。我一般会在主应用取走数据后主动删掉临时文件，形成一个闭环。

4.3 就地预览：适合快速确认类需求

有些场景用户只是想"看一眼"，不需要深度处理。比如分享一张图片进来，扩展直接展示一个预览，用户看完关掉就结束。这种方式对扩展的界面能力要求不高，但要处理好预览资源的加载和释放，尤其是大图，加载不当容易卡顿。

三种方式没有优劣，关键看业务。我的判断标准是：处理逻辑越轻、越不需要复杂界面，就越适合在扩展里直接完成；反之就越应该转交主应用。硬把重界面塞进扩展，最后往往是扩展生命周期和界面状态打架，问题一堆。

5. 那些文档不会写、但实际会绊倒你的细节

前面讲的偏框架，这一章全是实操里攒下来的经验，属于"知道的人不说、不知道的人踩了才懂"的类型。

5.1 扩展被重复拉起时的状态残留

系统可能在短时间内多次拉起同一个扩展，比如用户连续分享两次。如果你的扩展里有静态变量或者没清理干净的成员状态，第二次拉起时可能读到上一次的残留数据，表现为"分享的内容串了"。我的处理办法是：在onCreate里对所有关键状态做一次显式重置，不依赖默认值，确保每次拉起都是干净起点。这个习惯救过我好几次。

5.2 大内容分享的截断与超时

分享的内容如果特别大（比如很长的文本、高分辨率图片），传输和处理都可能出问题。文本过长可能被截断，图片过大可能加载超时。应对策略是：解析时对内容大小做判断，超过阈值就走"先落临时文件再处理"的路径，而不是硬塞在参数里。同时给处理流程加上超时保护，超时了给用户一个明确提示，而不是无限等待。

5.3 调试分享扩展的正确姿势

分享扩展的调试比普通页面麻烦，因为它由系统拉起，你没法直接断点跟进去。我的做法是：在扩展的关键回调里打足日志，通过日志确认扩展有没有被拉起、参数对不对、走到哪一步。另外，准备一个能主动触发分享的测试入口，方便反复验证，别每次都靠手动去别的应用里操作，效率太低。日志加上可控的触发入口，基本能覆盖大部分调试需求。

5.4 权限与可见性的隐性约束

扩展能访问的资源受应用整体权限约束，别假设扩展里能做的事和主应用完全一样。涉及文件、媒体等资源访问时，先确认权限声明齐全。另外，扩展的可见性受exported和意图匹配双重控制，两者任一不满足都不会被外部唤起，排查时要把这两个维度都过一遍，别只盯着一个。

6. 从能跑到好用：几个提升体验的取舍

把扩展跑通只是及格线，真正拉开差距的是体验细节。这一章聊几个我在迭代中做的取舍。

6.1 响应速度优先于功能完整

分享场景下，用户的心理预期是"点了就有反应"。所以扩展的第一优先级是快。我宁愿第一版只做最核心的接收和落库，也不愿为了功能全面而在onCreate里堆一堆初始化。功能可以后续迭代加，但第一印象的卡顿一旦形成，用户就会觉得"这个分享不好用"。先快起来，再慢慢补，这个顺序不能反。

6.2 失败路径要给明确反馈

分享处理失败是常事：数据格式不对、存储失败、转交超时。失败时最忌讳的是"静默"——用户点了分享，什么都没发生，也不知道成没成。我的原则是每条失败路径都有对应的轻量提示，告诉用户"没成功"以及"大概为什么"。提示不用很详细，但必须有，这是体验的底线。

6.3 类型声明的克制

前面提过配置里别声明太宽，这里再从体验角度强调一次。声明得越宽，被拉起的概率越高，但被拉起后处理不了的尴尬也越多。克制地声明你真正擅长的类型，让"出现即能用"成为常态，比"到处出现但一半用不了"要好得多。这个取舍在早期可能显得保守，但长期看是对的。

7. 一个可复现的最小落地骨架

讲了这么多，最后给一个能直接照着搭的最小骨架，把前面的要点串起来。注意这是骨架，业务逻辑按需填。

配置文件按第 2 章的结构声明扩展，type为share、exported为true、skills里声明sendData动作和实际支持的类型。实现文件里，onCreate只做参数解析和状态重置，把分享数据提取到成员变量；随后根据数据类型分派到对应处理分支，轻量内容直接落库并反馈，重内容转交主应用；处理完成后主动结束扩展。整个过程加足日志，配一个测试触发入口方便反复验证。

import ShareExtensionAbility from '@ohos.app.ability.ShareExtensionAbility'; import Want from '@ohos.app.ability.Want'; export default class ShareExtAbility extends ShareExtensionAbility { private sharedText: string = ''; private sharedUri: string = ''; onCreate(want: Want): void { // 每次拉起都重置状态，避免残留 this.sharedText = ''; this.sharedUri = ''; // 解析分享数据，做判空与类型校验 // 具体字段名以实际意图参数为准 console.info('ShareExt onCreate triggered'); } onDestroy(): void { // 清理临时资源 console.info('ShareExt onDestroy'); } }

骨架里的注释点就是最容易出问题的地方：状态重置、判空校验、资源清理。把这三处做扎实，扩展的稳定性就有底了。剩下的业务逻辑，按第 4 章的三种落地方式选一种往里填即可。

我在实际项目里最大的体会是：分享扩展这类系统托管的能力，"顺着系统的规矩来"比"按自己的想法来"重要得多。它的生命周期、拉起时机、数据传递方式都是系统定好的，你能做的是在这个框架内把细节做扎实。早期我总想着怎么让扩展"更自由"，结果处处碰壁；后来转变思路，老老实实按扩展的规矩写，反而顺了。如果你也在做类似的能力，建议先把配置和生命周期这两块吃透，其余的都是在稳定地基上盖房子。