web share target api 需完整 pwa 环境：有效 manifest.json（含 share_target、200响应、正确 content-type）、https、支持浏览器（chrome/edge ≥88，safari 不支持），且 share_target.action 必须为可访问的相对路径，仅支持 get 传文本/url，不支持文件接收。
Web Share Target API 不是“在 HTML 里写几行就能用”的功能，它依赖完整的 PWA 基础设施：必须有有效的 manifest.json、HTTPS 环境、注册的分享接收路由，且浏览器需支持（Chrome / Edge ≥ 88，Android WebView ≥ 88，Safari 尚未支持）。纯静态 HTML 页面直接加 <link rel="manifest"> 不会生效。
manifest.json 必须包含 share_target 且路径可访问
很多失败案例卡在这一步：share_target.action 指向的路径（如 /share-target）必须真实存在、能返回 HTML 页面，并且该页面能处理 URL 参数。不能是 404 或重定向到其他域名。
-
action值必须是相对路径（如/share-target），不能带查询参数或 hash -
method只能是"GET"或"POST"；但目前仅 Chrome/Edge 实际支持GET+application/x-www-form-urlencoded -
params中的键名（如"title"）必须与 URL 查询参数名完全一致，大小写敏感 - 确保
manifest.json文件可通过/manifest.json直接访问，HTTP 状态码为 200，Content-Type为application/manifest+json
接收页必须主动解析 location.search，不能只靠前端路由库
浏览器触发分享时，会以 GET 方式跳转到 share_target.action 对应路径，并把内容拼成查询参数（如 ?title=xxx&text=yyy&url=zzz）。如果你用 React Router、Vue Router 等前端路由，location.search 可能被拦截或丢失。
- 最稳妥做法：在接收页的顶层 JS 中用
new URLSearchParams(window.location.search)同步读取 - 避免依赖
useEffect或mounted钩子——用户可能从桌面快捷方式或系统分享面板直接打开，此时路由尚未初始化 - 如果使用 DVA，注意
location.search变化不一定会触发routermodel 的subscriptions，需手动监听window.onpopstate或用useEffect依赖location.search
Chrome 和 Edge 的实际行为与文档不一致
官方文档说支持 POST + multipart/form-data，但截至 2026 年 4 月，Chrome/Edge 仍只稳定支持 GET 方式传文本和 URL。文件类分享（files）在 Web Share Target 中**不可用**——它属于 Web Share API 的发送端能力，不是接收端。
- 尝试用
enctype: "multipart/form-data"会导致分享失败，系统弹出“无法分享到此应用”提示 -
share_target.params中不要声明"files"，浏览器会忽略 - 想收文件？只能退回到传统的
<input type="file">或拖拽上传，Web Share Target 不解决这个问题 - Android 上测试时，务必关闭 Chrome 的“精简模式”（在 chrome://flags 中禁用
#enable-sharing-hub），否则分享目标可能不显示
真正容易被忽略的是：Web Share Target 是一个“安装后才可靠触发”的机制。未添加到主屏幕的网页，即使 manifest 正确，系统也可能跳过你的应用。别在开发阶段反复点“分享”却没反应就怀疑代码——先把它作为 PWA 安装一次。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
