<p>不能。URLSearchParams 只处理 ? 后的查询字符串，对 # 后面的锚点（fragment）内容完全无视；正确做法是先用 window.location.hash.slice(1) 提取锚点内容，再传入 URLSearchParams 构造函数解析。</p>
URLSearchParams 能不能直接解析锚点（#）里的参数？
不能。URLSearchParams 只处理 ? 后的查询字符串，对 # 后面的内容完全无视。锚点部分属于 fragment，必须手动截取再传给 URLSearchParams 构造函数。
常见错误是直接写 new URLSearchParams(window.location) 或 new URLSearchParams(window.location.href) —— 这会把整个 URL（含协议、路径、锚点）当查询字符串解析，结果全是 undefined 或乱码。
- 正确做法：先用
window.location.hash.slice(1)拿到锚点内容（去掉开头的#） - 再判断是否为空：空字符串传给
URLSearchParams会创建一个空实例，不会报错但没数据 - 如果锚点里混用了
?（比如#?code=...&lang=js），要额外切掉开头的?，否则URLSearchParams会把?当作键名的一部分
如何从锚点提取并解码 HTML 代码块？
核心是两步：提取 + 解码。HTML 代码块通常需 Base64 编码后塞进 URL（避免特殊字符破坏结构），所以不能直接用 decodeURIComponent，得先 Base64 解码再转义。
注意：atob() 只支持 ASCII 字符，若原始 HTML 含中文或 emoji，必须用 encodeURIComponent + atob 组合，或改用 TextDecoder。
立即学习“前端免费学习笔记（深入）”；
- 推荐流程：
window.location.hash.slice(1)→URLSearchParams解析 →get('html')→atob()→decodeURIComponent()（如果之前 double-encoded） - 更健壮的做法：服务端生成链接时用
btoa(encodeURIComponent(html))，前端反向执行decodeURIComponent(atob(hashParams.get('html'))) - 别忘了 XSS 风险：解码后的 HTML 不能直接
innerHTML = ...，至少用DOMPurify.sanitize()过滤，或只允许预设标签
一键分享时怎么把 HTML 块塞进锚点？
关键不是“塞”，而是“编码后拼接”。直接拼 HTML 到 # 后会导致 URL 失效（、<code>&、空格等都会被浏览器截断或转义）。
实操中建议统一走 Base64：它输出纯字母数字++///=，安全可靠，且长度可控（比 encodeURIComponent 短约 30%）。
- 编码前先
encodeURIComponent(htmlString)处理 Unicode（防atob报错） - 再
btoa(...)得到 Base64 字符串 - 最后拼成
#html=xxx，用history.replaceState更新地址栏（不触发刷新） - 如果想兼容旧版 Safari（不支持
btoa处理 Unicode），改用TextEncoder+Uint8Array+btoa(String.fromCharCode(...))组合
为什么用锚点而不是查询参数（?）做分享？
因为锚点不触发页面重载，也不发请求到服务端，适合纯前端场景；而查询参数在 SPA 中容易被路由库拦截或重写，且刷新后可能丢失状态（取决于路由配置）。
但要注意：锚点变化不会被默认加入浏览器历史栈（除非显式调用 pushState），用户点后退可能跳过你的分享页。
- 如果需要前进/后退支持，用
history.pushState({ html: decoded }, '', `#${params.toString()}`) - 监听
hashchange事件比监听popstate更轻量，但注意首次加载时hashchange不触发，得手动检查window.location.hash - SEO 和爬虫基本忽略锚点内容，所以这种分享只适用于用户间点对点传递，别指望被搜索引擎索引
真正麻烦的是编码链路的一致性：前后端、不同浏览器、不同版本对 Unicode 的 Base64 处理差异很大，哪怕只差一次 encodeURIComponent，解码就会失败。建议把编解码逻辑封装成单个函数，全项目复用，别在各处手写。
