简介：面向网页开发者与在线协作场景的浏览器插件，适用于谷歌浏览器86及以上版本，可直接在浏览器中预览Word、Excel、PowerPoint及PDF文档，无需额外安装桌面办公套件。压缩包共398个文件，以HTML页面、CSS样式、JavaScript脚本和PNG图标为主，其中包含116个HTML结构文件、29个CSS样式表、10个JS交互脚本、165个PNG图标，并附带docx、xlsx、pptx示例文档，总大小仅10.67MB，便于开发者拆解在线预览的实现结构并集成到自有项目。已有3040人学习下载。借助这份资源，开发者可以获取完整的前端预览界面、样式配置与交互逻辑，配合示例文档快速验证效果；教育平台、项目管理系统可借此让用户在不离开网页的情况下查阅课件、报告与设计稿，减少本地环境依赖，降低文件外传带来的安全风险。适合需要轻量级在线预览能力的个人开发者与企业团队参考使用。
1. 为什么 86 版会成为 Office 在线预览插件的最低门槛
“在线预览 Office 文件”看起来是个老需求，真正做成一个 Chrome 浏览器上的插件却有不少细节值得抠。标题里的“适用于 86 以上”不是随手写的：Chrome 86 到 88 之间恰好跨过 Manifest V3 的转折点，大量企业内网机器停留在 86/87/88 三个版本上，还搭配着 Win7 环境里的旧版 chrome 一起工作，所以插件必须兼容这三个版本才谈得上“装完就能用”。这个插件要负载的场景很具体：用户看到 .docx/.xlsx/.pptx 链接时不下载、不用安装 Office 破解版，直接在当前标签页完成在线预览。
我会顺着做这类插件最常见的落地路径来讲：先选预览方案，再写插件骨架，最后把拦截链接、拼接查看器地址、处理内网文件这几个容易翻车的位置一一说清。全文围绕“谷歌浏览器在线预览 office 文件插件”这个真实需求展开，兼顾刚接触扩展开发的前端和要把预览能力集成进内部 OA 系统的工程师。
2. 预览方案选型：查看器服务、本地渲染库与拦截策略
做在线预览插件，第一步不是写代码，而是定“谁来渲染”。渲染方决定了插件是改链接还是抓文件，也决定了内网能不能用。
2.1 三种主流通用做法对比
| 方案 | 预览保真度 | 对内网/本地的支持 | 需要自建服务 | 主要限制 |
|---|---|---|---|---|
| Microsoft Office Online Viewer | 高，接近 Office 原生 | 不支持，src 参数必须指向公网可访问的 URL | 否 | 受保护文件、超大文件会被服务端拒绝 |
| Google Docs Viewer | 中高 | 不支持 | 否 | 部分复杂排版和图表会走样 |
| 纯前端解析库（docx-preview、SheetJS、pptx2json） | 取决于所选库 | 支持，能直接渲染 ArrayBuffer 与 Blob | 否 | 样式差异明显，宏、批注等会丢 |
表格里前两项本质是同一种思路：插件不改动原始文件，只把链接转成第三方在线预览平台的地址。以微软的 Office Online Viewer 为例，它的入口固定为https://view.officeapps.live.com/op/view.aspx?src=编码后的文件URL，浏览器打开这个地址后，微软服务器自己去抓取src指向的文件并渲染成网页。开发者要做的事情只是把普通链接替换成这个地址，工作量极小。
纯前端解析库则是另一个方向：插件通过fetch把文件内容抓下来，交给 JS 库逐段渲染。好处是文件不必公开，内网 OA 也能用；坏处是每种 Office 格式要选对应渲染库。Word 一般用 docx-preview，Excel 复杂样式建议 SheetJS 社区版，PPT 现成可用的库比较少，多数团队只做前三者。
2.2 Chrome 87 / 88 的 Manifest 差异如何影响插件权限
标题里强调 86 以上，和 Manifest 版本直接相关。Chrome 88 是第一个正式支持 Manifest V3 的版本，从 2021 年起 Chrome 应用商店不再接受新的 Manifest V2 插件。也就是说，新开发的插件必须以 MV3 为基线，但目标浏览器如果还在 87 甚至 86，MV3 的接口它不认识。
实际开发中我的处理方式是维护两份清单，由构建脚本按目标版本输出。84 到 87 走 MV2 包，88 及以上走 MV3 包。这里最关键的区别有三个：MV2 的后台脚本是常驻的background.scripts，MV3 改成了非持久的service_worker；MV3 把原来webRequest里的拦截能力拆成了declarativeNetRequest，动态改请求头变复杂；MV3 要求所有在页面里执行的脚本都必须在web_accessible_resources里显式声明。
// build-manifest.js，在打包时选择版本 const fs = require("fs"); const base = JSON.parse(fs.readFileSync("src/manifest.json", "utf8")); const target = process.argv[2]; // "mv2" 或 "mv3" if (target === "mv2") { base.manifest_version = 2; base.minimum_chrome_version = "86"; base.background = { scripts: ["background.js"] }; delete base.action; } else { base.manifest_version = 3; base.minimum_chrome_version = "88"; base.background = { service_worker: "background.js" }; } fs.writeFileSync(`dist/manifest.${target}.json`, JSON.stringify(base, null, 2));打包时把生成的 manifest 放入对应目录，就能让同一套业务代码同时覆盖 86 和 88+。注意 MV2 的background.scripts和 MV3 的service_worker不能同时出现，否则浏览器解析清单会直接报错。权限方面，MV2 的permissions里写上<all_urls>是常态，MV3 则要求拆分到host_permissions，并且安装时给用户的提示更醒目，所以在 3.1 节我会把权限尽量收敛。
2.3 为什么“只改链接”比“代理下载再渲染”更适合 86+ 内网
有经验的读者可能会问：既然内网文件不公开，那插件能不能自己抓文件再渲染？可以，但代价比想象中高。插件要抓文件，必须拿到字节流；OA 系统普遍带登录态，插件抓的时候要处理 cookie、token、甚至动态签名。抓到之后，还要在插件内部实现一套完整的文件类型嗅探和渲染状态机，工作量接近重写一个迷你版 Office。
更稳妥的路线是让插件保持“轻”，只做两类事：把公网文件的链接改写成查看器地址；把内网文件的链接标记出来，交给一个内置的精简预览页去拉取渲染。这样即便内网文件因为鉴权拉不到，用户也能看到明确报错而不是白屏。对于 86 到 88 这个区间的老浏览器，这种轻量设计还避免了对新 API 的依赖，兼容性压力小很多。
3. 最小可用的 MV3 插件：改链接、拼查看器地址、右键兜底
现在进入代码层。我以 MV3 为范例，给出一个能直接装进 Chrome 的骨架，随后解释参数。
3.1 manifest.json 里的关键字段与权限解释
{ "manifest_version": 3, "name": "Office 在线预览助手", "version": "1.0.0", "description": "把 office 链接转为在线预览地址的 chrome 插件", "minimum_chrome_version": "88", "permissions": ["contextMenus", "storage"], "host_permissions": ["http://*/*", "https://*/*"], "background": { "service_worker": "background.js" }, "content_scripts": [ { "matches": ["http://*/*", "https://*/*"], "js": ["content.js"], "run_at": "document_idle" } ], "action": { "default_title": "Office 在线预览助手" } }host_permissions写http://*/*和https://*/*是为了让内容脚本能进入所有页面；如果担心权限范围过大，可以收敛成常用 OA 域名列表，但那样换一个内网系统就要改一次配置。run_at: document_idle表示等 DOM 解析完成后再执行改链接逻辑，能避免在文档流中过早操作导致链接被后续脚本还原。action字段在 MV3 里代替了原来的browser_action，我这里只留了标题，代码里没有弹窗时它就是个“好看的图标”。
3.2 内容脚本：把 office 链接换成在线预览地址
// content.js const OFFICE_RE = /\.(docx?|xlsx?|pptx?|xls|doc|ppt)(\?.*)?(#.*)?$/i; function previewUrlOf(originalUrl) { return "https://view.officeapps.live.com/op/view.aspx?src=" + encodeURIComponent(originalUrl); } function convertLink(link) { if (!link || link.dataset.officeDone) return; if (!OFFICE_RE.test(link.href)) return; link.dataset.officeOriginal = link.href; link.href = previewUrlOf(link.href); link.dataset.officeDone = "1"; } document.querySelectorAll("a[href]").forEach(convertLink); const observer = new MutationObserver((mutations) => { for (const mutation of mutations) { for (const node of mutation.addedNodes) { if (node.nodeType !== 1) continue; if (node.matches && node.matches("a[href]")) { convertLink(node); } if (node.querySelectorAll) { node.querySelectorAll("a[href]").forEach(convertLink); } } } }); observer.observe(document, { childList: true, subtree: true });这段代码的核心是OFFICE_RE和previewUrlOf两个部分。正则把.doc、.docx、.xls、.xlsx、.ppt、.pptx结尾的链接都匹配出来，兼容最常见的 Office 扩展名；带查询参数的链接也能命中，因为正则用(\?.*)?覆盖了后半段。encodeURIComponent会把链接里的冒号、斜杠、问号都转成百分号编码，防止src参数在拼接时把原始 URL 里的?误当成查看器自己的参数。
MutationObserver 用于处理异步加载的列表页和详情页。很多 OA 系统是 SPA，文档列表在用户滚动时才渲染，观察整个文档的childList变化可以保证新出现的链接也会被改掉。
3.3 查看器 URL 拼接规则与常见错码
微软 Office Online Viewer 的入口固定是view.officeapps.live.com/op/view.aspx，核心参数只有一个src。正确的拼接方式是：
https://view.officeapps.live.com/op/view.aspx?src=https%3A%2F%2Fexample.com%2Fdocs%2Fdemo.docx常见错误是少做一次编码，或者把encodeURIComponent用成全量编码。前者会得到类似?src=https://example.com/docs/demo.docx?x=1的结果，后者会把原始 URL 里的点号也编码掉，某些网关会拒绝解析。正确的参数写法是：
const encoded = encodeURIComponent("https://example.com/docs/demo.docx?x=1"); // 结果: https%3A%2F%2Fexample.com%2Fdocs%2Fdemo.docx%3Fx%3D1注意encodeURIComponent不会编码单引号和括号，如果目标文件 URL 里恰好有这两种字符，建议再加一层替换逻辑替换为百分号编码，否则查看器服务端解析时可能截断地址。
3.4 右键菜单兜底与动态页面的刷新策略
并不是所有 office 文件都挂在<a>上，有些系统用按钮触发下载，有些是 JS 拼接出来的 blob 地址，内容脚本无从下手。这种情况我会在后台脚本里注册一个右键菜单，用户在链接上点右键就能预览。
// background.js（MV3） chrome.runtime.onInstalled.addListener(() => { chrome.contextMenus.create({ id: "office-preview", title: "在线预览此文档", contexts: ["link"] }); }); chrome.contextMenus.onClicked.addListener((info, tab) => { if (info.menuItemId !== "office-preview" || !info.linkUrl) return; const url = "https://view.officeapps.live.com/op/view.aspx?src=" + encodeURIComponent(info.linkUrl); chrome.tabs.create({ url }); });info.linkUrl只在contexts: ["link"]时可用，这是右键菜单 API 的限制。这里的业务逻辑和内容脚本完全一致，等于给了用户一条不依赖页面结构的逃生通道。
提示：如果右键菜单没出现，多半是后台脚本注册失败。MV3 的 service worker 会在空闲时被回收，重新加载插件后需要点一次扩展图标唤醒，再试右键。
4. 打开预览就空白：按这四步定位问题
预览插件能写好，但比写好更重要的是会排错。在线预览这个场景里，白屏和“文件不存在”两大类问题几乎覆盖 90% 的故障，下面按排查顺序展开。
4.1 先看查看器返回的是 4xx 还是错误页
当用户报告预览打不开，我的第一步不是改代码，而是让他打开浏览器开发者工具，切到 Network 面板，找到那个以view.officeapps.live.com开头的请求。看状态码：
| 状态码/现象 | 可能原因 | 第一步检查 |
|---|---|---|
| 401/403 | 源文件带鉴权，查看器服务端拿不到文件 | 在无痕窗口打开 src 里的原始地址，确认是否要登录 |
| 404 | 原始文件已删除，或文件 URL 拼接错误 | 复制 src 参数解码后直接访问 |
| 429 | 请求太频繁或大文件超限 | 稍等重试，换小文件验证 |
| 白屏且状态码 200 | 查看器框架加载成功但文件流未返回 | 看 Response 内容是否包含错误提示文本 |
排查这类问题有一个稳的终端指令：把查看器地址直接拿来跑 curl，能看完整 HTTP 头。
curl -I "https://view.officeapps.live.com/op/view.aspx?src=https%3A%2F%2Fexample.com%2Fdocs%2Fdemo.docx"如果返回200 OK，问题基本出在浏览器端缓存或扩展权限上；如果返回 404/403，就需要回头检查src参数里的原始链接是否公网可达。这个命令里-I只取响应头，不要省略，否则会下载整个渲染页面，浪费时间。
4.2 内网文件打不开是必然的：正确姿势是本地渲染
同事常把问题描述成“chrome 默认会拦截本地网络”。严格说，Chrome 拦的是网页发往内网资源的 Private Network Access 请求，和查看器打不开是两码事。真正的根源在于微软查看器是服务端抓取：你拼好src=http://localhost:8090/demo.docx后，发起请求的是微软服务器，不是你的浏览器。微软服务器访问不到你的 localhost，当然返回文件不存在。
所以内网文件想在线预览，必须绕开第三方查看器，改用本地渲染库。常见做法是插件提供一个独立的预览页，页面上用 docx-preview 渲染 Word：
<!-- preview.html --> <script type="module"> import { renderAsync } from "./lib/docx-preview.min.js"; const params = new URLSearchParams(location.search); const fileUrl = params.get("url"); const res = await fetch(fileUrl); const blob = await res.blob(); renderAsync(blob, document.querySelector("#host")); </script>这个页面由扩展自己打开，脚本文件必须放在扩展包内的lib目录，因为 MV3 默认禁止远程代码。fetch能不能跨域同样受 CORS 限制，内网服务需要响应头里带Access-Control-Allow-Origin，否则只能降级做法：插件后台脚本fetch后再把字节流交给预览页。后台扩展拥有host_permissions权限，可以绕过页面 CORS，但会多一次转发，执行效率要自己权衡。
4.3 链接改不动的三处根源：运行时机、SPA 路由、权限拦截
内容脚本最常见的失败原因是运行时机。run_at: document_idle虽然等到了 DOM 解析完，但很多前端框架在 idle 之后还会做一次异步渲染，链接是动态拼接的。解决办法是把 MutationObserver 的监听范围从addedNodes扩大到包含attributeChanged，或者像下面这样在页面路由变化时补一次扫描：
// 监听 history 路由变化，SPA 切页后重新扫描 const originalPushState = history.pushState; history.pushState = function () { setTimeout(() => { document.querySelectorAll("a[href]").forEach(convertLink); }, 300); return originalPushState.apply(this, arguments); };第二处根源是权限拦截。如果点击链接后浏览器直接跳到一个错误页，显示ERR_BLOCKED_BY_CLIENT，说明页面上有脚本把扩展改写后的地址又还原了，或者 CSP 里default-src限制了对view.officeapps.live.com的连接。前者要查看页面里是否有前端路由对a标签做统一处理，后者只能让后端在 CSP 里追加一条frame-src白名单。
第三处是零碎问题：内容脚本报错导致后续代码不执行。常见情况是node.matches在旧版 Chrome 中需要带前缀，或页面本身有全局变量把MutationObserver污染了。处理方式是给整个脚本包一层try { } catch (e) { console.warn("[office-preview]", e); }，至少保证出错时能留下日志。
5. 用本地 http.server 验证插件链路的两个压测点
代码写完总要有个能反复跑的验证环境。最适合这类插件的验证方式是本地起一个静态文件服务，配合chrome://extensions/页面里的“加载已解压的扩展程序”完成端到端测试。
5.1 在 8090 端口搭一个包含 office 文件的测试页
python -m http.server 8090 --bind 0.0.0.0准备工作先在当前目录放一个index.html，里面写上几个指向docs/demo.docx、docs/report.xlsx的链接，然后把对应的 Office 文件放进docs目录。启动后访问http://localhost:8090/index.html，右键点击 docx 链接，选择“在线预览此文档”，观察新标签页的地址栏和 Network 面板。
这个环节只验证插件链路本身，不验证真实渲染。因为预览地址指向view.officeapps.live.com时，微软服务器并不能访问到你的 localhost，测试目标是确认两件事：右键菜单的linkUrl提取正确，且encodeURIComponent后生成的地址符合预期格式。只要新标签页打开的是https://view.officeapps.live.com/op/view.aspx?src=http%3A%2F%2Flocalhost%3A8090%2Fdocs%2Fdemo.docx，说明插件链路已通。
5.2 双 manifest 打包验证，重点测 86 行为
按 2.2 节的构建脚本生成dist/manifest.mv2.json和dist/manifest.mv3.json后，把对应目录拖进chrome://extensions/页面。86 版本不识别 MV3 清单，这会直接让你确认自己的目标版本到底该打哪个包。
验证步骤分两头：在 88+ 的浏览器里用 MV3 包，确认内容脚本改链接和右键菜单都正常；在 86/87 的浏览器里用 MV2 包，确认真机上没有chrome.action对象导致的后台脚本报错。如果 86 版本里出现“清单文件缺失或不可读”，优先检查manifest_version是否被构建脚本误写成 3。
生产环境中，这个插件的最简形态可以不做任何服务端配套，仅在内容脚本里保留convertLink，右键菜单和本地预览页都作为可裁剪模块。如果不需要右键预览，把contextMenus权限和相应代码删掉，插件在 Chrome 应用商店审核时的权限提示会更干净，误报风险也小。
本文还有配套的精品资源，点击获取
