简介这份资源是 Axure 原型工具的 Chrome 浏览器扩展插件包面向使用 Axure 制作交互原型、希望在浏览器中直接预览与交付成果的产品经理、交互设计师及前端协作人员。压缩包共 8 个文件、约 25KB以两个 JavaScript 脚本承担扩展的核心逻辑manifest.json 声明插件配置background.html 作为后台页面另有 3 张不同尺寸的 PNG 图标和一份说明文本各目录保持原始层级解压后即可按 Chrome 扩展方式加载。目前已有 385 人学习下载。对于需要频繁向团队演示原型、验证交互细节的读者这份插件可省去反复导出与上传的环节让原型在本地浏览器中直接打开也便于统一图标资源、排查插件加载失败等问题包内说明文本记录了基本用法整体体量轻巧无需额外依赖即可使用适合初次接触 Axure 浏览器插件、想快速跑通流程的设计人员参考。1. 一份 Axure 导出包配一个 Chrome 扩展卡住的往往是本地打开这一步把 Axure 导出的 HTML 原型压缩包发给同事对方双击 start.html页面停在加载动画上转圈控制台一片 file:// 的红色报错——这种场面我一年要碰上十几次。问题多半不在原型本身而在浏览器本地文件协议下原型依赖的脚本和数据加载不起来于是就有了 Axure 谷歌插件、也就是常说的 Chrome 扩展这类东西。它干的活很单纯把本地页面缺的那一环补上让双击 HTML 就能看交互。这篇写的是这个扩展从哪来、怎么离线装、导出参数怎么配、以及一堆人踩过的坑适合天天出原型的产品经理、要给客户现场演示的交互设计也适合被叫去帮忙看看为什么打不开的前端。2. file:// 打不开的真相扩展在页面和浏览器之间补了哪一环2.1 双击 HTML 之后浏览器到底拦了什么Axure 发布出来的原型不是一张静态页面而是一个小型前端应用。导出目录里通常有这么几类东西入口的 start.html放样式的 resources 目录放页面数据和站点地图的 data 目录放图片素材的 files 目录以及少数情况下才出现的 plugins 目录。入口 HTML 本身很薄真正的页面结构是运行时由脚本去 data 目录里读 document.js、再渲染出来的。关键就在运行时去读这四个字。当页面地址是 file:///.../start.html 时Chrome 对同目录下其他文件的读取有一套额外限制脚本发起的本地资源请求会被拦下来控制台里看到的就是跨域或者被拒绝的报错。表现到界面上就是那个转圈的加载动画永远不结束或者干脆白屏。很多人第一反应是文件损坏了重新导出、重新压缩、换台电脑折腾一圈发现还是白屏因为问题从来不在文件上。早年间有个命令行开关可以让浏览器放开本地文件访问但那属于改浏览器启动方式的路子每台机器都要配一遍给外部人员演示时基本不可行。真正适合分发场景的解法只有两个方向要么给浏览器装一个能补齐权限的扩展要么把原型放到一个 HTTP 服务上去访问。前者是这份资源要解决的事后者我在最后一章会给出具体命令。理解这一层之后你就不会再把打不开归咎于原型质量而是清楚地知道这是浏览器安全模型和本地文件交付方式之间的结构性矛盾。2.2 扩展的工作方式一次注入和一次握手这个扩展的职责窄得超出很多人想象。它不解析原型、不渲染页面、也不改任何交互逻辑它做的事情本质上是两件一是声明自己有权在 file:// 页面里运行二是给页面脚本提供一个可被探测到的标记。流程是这样的。原型入口脚本启动时会先做一次能力探测看当前环境里有没有扩展留下的对象或者通信通道。探测不到就渲染一个提示页告诉你需要安装对应的浏览器扩展探测到了才继续往下走去加载 data 目录里的页面数据。这个过程对使用者是完全透明的页面上看不到任何正在检测的字样所以它更像个黑匣子——你只能通过结果反推它有没有生效。也正因为职责这么窄它几乎没有配置项。装好、打开文件访问权限、刷新页面三步就完事。凡是需要你填路径、选目录、配端口的所谓增强插件都不是这个东西别混。这里有个容易被忽略的点扩展只解决浏览器允许读本地文件这一件事。如果原型目录本身被拆散了——比如有人只把 start.html 单独拷出来发微信——那扩展装得再对也没用因为 data 目录根本不在。所以排查时永远先看目录完整性再看扩展状态顺序反了会浪费大量时间。2.3 三条打开路径的横向对比同样是看一个 Axure 原型能走的路不止一条。选哪条取决于你是自己看、发给同事看还是给外部客户看。打开方式是否需要扩展首次配置成本交互完整度适合场景双击 HTMLfile://需要每台机器装一次扩展并开文件访问权限完整内部评审、自己反复看本地 HTTP 服务不需要需要有 Python 或 Node 环境起一条命令完整开发联调、需要多设备访问托管到在线地址不需要需要上传可能涉及账号取决于托管方式对外演示、跨地域协作这张表里最容易被低估的是第二行。很多团队一遇到打不开就去装扩展其实只要机器上有 Python一条命令就能起个静态服务浏览器按 http:// 访问所有本地文件限制瞬间消失连扩展都不用碰。缺点是每换一次目录就得重起一次而且对方得会敲命令所以它更适合技术团队内部不适合发给非技术的接收方。第一行的优势是零依赖收包的人只要装好扩展就能看不需要任何运行环境。代价是每台新机器都要走一遍安装流程而且这一步经常卡在权限开关上第 3 章会细说。第三行看起来最省事实际上把问题转移到了别处上传之后的原型是否还会引用到本地绝对路径、字体能不能带上去、访问权限怎么控都是新的坑。我的习惯是按接收方分内部设计评审走本地文件加扩展开发联调走本地服务对外演示走托管。三种方式不是互斥的同一个原型完全可以同时准备两套交付物。2.4 分清三种安装包商店版、CRX 文件、解压目录在动手之前先认清手上是什么能省掉一半的失败尝试。第一种是从浏览器扩展商店直接安装最省事点一下就好后续还能自动更新。限制在于商店访问情况和账号环境公司网络做了策略限制的机器上经常装不上。第二种是后缀为 .crx 的单文件包本质是一个带签名头的压缩包早年可以直接拖进扩展管理页安装现在主流 Chrome 版本已经不允许这种来源的安装拖进去只会弹一句无法从该网站添加应用、扩展程序和用户脚本。第三种是解压后的目录里面能看到 manifest.json、若干 js 和图标文件这种可以用开发者模式加载是目前最稳的离线路径。判断方法很直接看后缀.crx 是单文件目录是有 manifest.json 的文件夹。如果拿到的是 .crx 又装不上别急着找旧版浏览器直接解包成目录走开发者模式第 3 章给了具体脚本。顺带说一句有些资源包里会把扩展和原型样例混在一起打包解压后一堆同名目录分不清哪个是扩展。认准一个特征就行扩展目录的根下必然有 manifest.json且里面会有 content_scripts 或 web_accessible_resources 字段原型目录的根下是 start.html 和 data、resources 这些。3. 离线把扩展装进 Chrome解包、加载、验证的三段式3.1 先读 manifest再决定怎么装不管拿到的是 CRX 还是目录第一步都是把 manifest.json 翻开看一眼。这个文件决定了扩展能不能在你当前的浏览器上跑起来比任何安装教程都可靠。重点看三个字段。manifest_version 是版本号早期扩展写 2新一些的写 3两者的后台脚本模型不一样写 2 的老包在新版浏览器上可能加载后直接报错、图标变灰。content_scripts 里的 matches 决定它能注入哪些页面如果里面没有 file:///* 这类匹配规则那它压根不是给本地文件用的扩展。permissions 和 web_accessible_resources 则关系到它能不能把资源暴露给页面。下面这段脚本能把关键信息一次打出来比手动翻 JSON 快得多# inspect_manifest.py # 用法: python inspect_manifest.py ./extension/manifest.json import json import sys path sys.argv[1] with open(path, encodingutf-8) as f: m json.load(f) print(name :, m.get(name)) print(version :, m.get(version)) print(manifest_version:, m.get(manifest_version)) # content_scripts 决定注入范围重点看有没有 file:// 匹配 for i, cs in enumerate(m.get(content_scripts, [])): print(fcontent_script[{i}] matches:, cs.get(matches)) print(fcontent_script[{i}] js :, cs.get(js)) # 部分扩展靠这个字段把资源暴露给页面 war m.get(web_accessible_resources) print(web_accessible_resources:, war if war else 无)代码逻辑很直白读 JSON、按字段打印。参数只有一个 manifest.json 的路径。判断标准是——如果 manifest_version 是 2先做好它在当前浏览器上加载失败的心理准备如果所有 matches 都是 http:///而没有 file:// 相关规则那这个包解决不了本地原型的问题装上也白装。这一步花三十秒能避免后面半小时的瞎试。3.2 解包 CRX7-Zip 直开和一段 Python 脚本如果是 .crx 文件需要先变成目录。两条路看手头工具。第一条用 7-Zip 或者系统自带的解压工具直接打开 .crx多数情况下能像普通 zip 一样浏览并解出内容因为 zip 的中央目录结构还在文件尾部。缺点是某些工具会因为前面多出来的签名字节报文件损坏这时候就走第二条。第二条写几行代码把签名头切掉再解压。CRX 文件在 zip 数据之前有一段二进制头找到 zip 的起始标记从那里截断保存就是标准 zip# crx_unpack.py # 用法: python crx_unpack.py axure_extension.crx ./ext_out import io import sys import zipfile def strip_header(raw: bytes) - bytes: # zip 的本地文件头魔数是 PK\x03\x04从它开始才是真正的压缩数据 idx raw.find(bPK\x03\x04) if idx 0: raise ValueError(未找到 zip 起始标记文件可能损坏或不是 CRX) return raw[idx:] src, dst sys.argv[1], sys.argv[2] with open(src, rb) as f: body strip_header(f.read()) with zipfile.ZipFile(io.BytesIO(body)) as zf: zf.extractall(dst) print(f已解出 {len(zf.namelist())} 个文件到 {dst})参数两个第一个是 CRX 路径第二个是输出目录目录不存在会自动创建。核心就一句raw.find(bPK\x03\x04)因为 CRX 的头部长度在不同版本里不固定写死偏移量必然翻车按魔数定位才稳。解完之后打开输出目录确认一下根下应该有 manifest.json还可能有 _locales 目录放多语言文案有 icons 放图标。如果有嵌套了一层同名目录把里层提到外层因为加载扩展时选错层级会直接报清单文件缺失。3.3 开发者模式加载以及那个必须手动打开的开关解压好之后进浏览器的扩展管理页地址栏输入 chrome://extensionsEdge 是 edge://extensions右上角打开开发者模式左上角出现加载已解压的扩展程序点它选中刚才解出来的目录。加载成功的话卡片会出现在列表里图标正常、没有红色报错。到这一步很多人以为完事了然后打开 start.html 发现还是提示要装扩展——问题就出在一个默认关闭的开关上。找到刚加载的扩展卡片点详情往下翻有一项叫允许访问文件网址默认是关的。必须手动打开。这个设计是浏览器的安全考虑扩展能读本地文件风险比只能读网页高。但它藏在二级页面里官方文档也不会主动提示于是成了最高频的翻车点血泪经验基本都在这儿。打开开关之后不需要重装但已经打开的 start.html 标签页要关掉重开因为权限变更不会热更新到已有页面。刷新一下加载动画应该就消失了。顺带提一句企业环境如果扩展管理页里加载已解压的扩展程序按钮是灰的或者加载后被自动移除那是组策略在管需要让 IT 把扩展 ID 加进允许列表自己折腾没用。3.4 三条验证手段确认扩展真的接管了页面装完不等于生效得验证。我一般按从粗到细三步走。第一步看界面。重新打开 start.html如果之前那个需要安装扩展的提示页没了直接进了原型首页基本就成了。这步最快但也最容易被误判——有些原型首屏本来就是空白页看着像没加载成功。第二步看控制台。F12 打开开发者工具切到 Console刷新。如果还残留 file:// 相关的报错说明扩展没接管如果报错干净了Network 面板里 document.js、sitemap.js 这些请求状态是 200 或 304那就是正常的。这一条比看界面可靠得多。第三步看扩展自身状态。回到扩展管理页如果卡片上有错误按钮点开能看到具体异常比如某条规则匹配失败、某个 API 不被当前版本支持。这一步主要用来定位装了但没生效的情况——错误详情会直接告诉你是权限问题还是版本兼容问题。三句话记住界面看结果控制台看链路扩展页看自身。三层都过了再交付别在客户面前第一次打开。4. 导出参数决定后面一半的坑Axure 生成 HTML 的配置清单4.1 发布对话框里真正影响兼容性的几项扩展装对了原型还是可能出问题因为毛病可能出在导出那一刻。发布 HTML 的对话框选项不少不同大版本措辞也不完全一样但下面这几项是真正会咬人的。配置项常见默认建议值影响生成 HTML / Generate HTML勾选必须勾选不勾只出图片和说明没有交互包含页面说明视情况交付给客户时勾选关掉后备注页消失评审时少一半信息字体处理使用系统字体统一字体栈或内嵌对方没装同款字体时行高错位图片质量中等演示用高中等存档用高直接影响包体积和加载速度视口 meta勾选保持勾选移动端预览时缩放行为不同密码保护无对外交付时设置明文原型任何人拿到都能看字体这一项值得单独说。原型里写的字体如果依赖接收方系统里恰好装了同款换台机器就会整版错位尤其是中英文混排的行高。稳妥做法是在源文件里就把字体收敛到系统通用字体或者导出时选择把字体打进包里代价是包体积涨得明显。我见过最典型的场景是设计在自己机器上排得整整齐齐发给客户后所有按钮文字溢出边框返工三小时。图片质量则和加载速度直接冲突。一个几十页的中保真原型全用高质量导出包能到几百兆双击打开要等十几秒很多人会误判为卡死了。演示场景用中档足够屏幕上看不出差别。4.2 目录结构和路径大小写跨系统交付的第一道坎导出的目录不是随便放的它的内部引用是相对路径一旦结构被破坏就全线崩。最常见的破坏方式是只发入口文件。有人觉得 start.html 就是全部单独拷出来发过去对方打开自然是白屏——data 和 resources 都不在。正确做法是整个目录一起打包压缩时选中父级文件夹而不是进去全选文件否则解压出来是散的。第二个坑是路径大小写。macOS 的默认文件系统对大小写不敏感Windows 也不敏感但某些 Linux 环境和部分静态服务器是敏感的。如果导出后有人手动改过文件名的大小写在 Windows 上一切正常传到服务器上就 404。跨系统交付前把目录里所有文件名扫一遍统一成小写是个便宜又有效的习惯。第三个坑是中文名和空格。目录名带中文、带空格在本地双击通常没事一旦走 HTTP 服务或者邮件附件转发就容易在某一环被转义成乱码导致相对路径断掉。我一般要求导出目录名只用英文、数字、下划线长度控制在合理范围避免接近系统的路径长度上限。4.3 三种交付形态对应三种接收方同一份原型发给不同的人要用不同形态混着来必出事。给内部同事直接发整个目录的压缩包附一句话说明要装扩展。同事是技术或设计岗装扩展不是门槛。压缩包命名带上日期和版本号避免出现最终版_最终版2这种一看就没人维护的东西。给外部客户优先走在线地址或者把目录放到一台内部可访问的静态服务器上发链接。这样对方什么都不用装。如果必须发文件就在包里附一个一页纸的说明写清楚打开方式和可能遇到的提示别指望对方自己搜。给开发做对照目录要保留完整同时把页面说明一并导出开发需要看交互描述和字段备注只有界面等于让他们猜。这种情况下包体积大一点完全可以接受。三种形态的共同点是目录结构不能被改动。任何帮你去掉几个没用的文件夹的好心操作都会让接收方打开时白屏。5. 排查与避坑五条把人劝退的现场记录5.1 五个真实翻车现场按现象—原因—解决拆开第一条扩展装了页面还是提示要安装。现象是扩展管理页里卡片正常、没有报错但打开 start.html 仍然显示提示页。原因是允许访问文件网址这个开关没打开扩展虽然加载了但没有读取本地文件的权限。解决是进扩展详情页把开关打开然后关掉已打开的标签页重新打开——注意是重开刷新有时候不生效。这条我在不同机器上至少遇到过二十次属于第一顺位排查项。第二条加载动画一直转控制台一堆 404。现象是页面不白屏但永远停在加载状态Network 面板里 document.js、sitemap.js 之类的请求全是 404 或者被拒绝。原因通常是目录不完整比如只拷了 start.html或者压缩包里漏了 data 目录。也可能是解压时被杀毒软件拦掉了部分 js 文件。解决是回到导出源头重新整目录打包解压后核对 start.html 同级是否有 data、resources、files 三个目录。第三条把 CRX 拖进扩展页弹出无法从该网站添加。现象是拖拽安装被拒绝提示来源不受支持。原因是新版浏览器已经禁止非商店来源的 CRX 直接安装这是策略层面的变化跟包本身没关系。解决就是第 3 章那条路解包成目录开开发者模式加载已解压的扩展程序。别去找旧版本浏览器那条路维护成本更高。第四条自己电脑正常同事电脑字体全乱。现象是同一个包在自己机器上排版精准到对方机器上文字溢出、行高错位、按钮变形。原因是原型依赖了本机安装的字体对方系统没有同款。解决是在源文件里把字体换成通用字体栈或者导出时选择把字体资源一并打包已经导出的包只能回源改。这类问题在跨 macOS 和 Windows 交付时出现频率极高值得在交付清单里单列一条。第五条双击 HTML 直接跳到了别的浏览器。现象是文件被系统默认浏览器接管打开后发现提示装扩展但装的是另一个浏览器的扩展。原因是系统默认程序设置跟原型无关。解决是右键选择打开方式指定到装了扩展的那个浏览器必要时设为默认。这条看着低级但在混合系统的团队里天天发生。5.2 一张按顺序走的排查表遇到打不开不要跳步按下面的顺序走能覆盖九成情况。顺序检查项判断依据不通过怎么办1目录是否完整start.html 同级有 data、resources、files重新整目录打包2用的是哪个浏览器地址栏协议与浏览器图标指定打开方式3扩展是否加载扩展管理页有卡片、无红字重新加载已解压目录4文件访问开关详情页允许访问文件网址为开打开后重开标签页5控制台报错类型file:// 相关还是 404前者查权限后者查目录这张表的顺序不是随便排的。前两项成本最低、命中率最高五分钟能排掉一半问题扩展和权限放中间因为要动浏览器设置控制台放最后因为它需要一点读报错的经验。很多人反着来一上来就 F12 看报错结果被一堆无关的警告带偏。补充一个细节如果原型是从别人那里二次转发的先问清楚对方导出时用的什么设置、有没有改过目录名。二手包的坑比一手包多得多问一句能省半小时。6. 进阶用本地静态服务绕开扩展并把自检固定成习惯装扩展这条路走得通但它有个绕不过去的成本——每台机器都要配一次且那个权限开关藏得深。技术团队内部我更推荐另一条路起一个本地静态服务用 http:// 访问扩展、权限、跨域问题一次性全部消失。做法简单到不像话。进到原型目录起一条命令# 在原型目录start.html 所在目录执行 python3 -m http.server 8080 --bind 127.0.0.1 # 然后在浏览器打开 http://127.0.0.1:8080/start.html参数说明8080 是端口被占用就换 8081、8082--bind 127.0.0.1表示只监听本机如果想让同网段的手机或同事访问改成--bind 0.0.0.0然后用本机内网 IP 加端口访问。没有 Python 环境的话Node 生态里有等价的静态服务工具任选其一即可。注意这条服务只在命令窗口开着的时候有效关掉就没了不是常驻。起完服务先用一条命令确认入口能返回 200再叫人来看curl -s -o /dev/null -w %{http_code}\n http://127.0.0.1:8080/start.html # 输出 200 表示入口可达404 多半是目录选错了502 一般是端口被别的进程占了我自己交付前固定跑四步目录完整性核对一遍、目标浏览器里打开一次、控制台无 file:// 报错、换个字体环境比如用另一台机器或远程桌面看一眼排版。这四步加起来不到五分钟但省下来的返工时间远超这个数。说个教训。早年我图快导出的包在自己机器上验证过就直接发给客户结果对方打开是白屏现场演示被迫改成截图讲解。后来才知道他那台机器没装扩展也没开文件访问权限——而我在说明里一个字都没提。从那以后我每次发包前都强制走一遍上面四步并且在压缩包里放一个两行的 readme写明打开方式和可能遇到的提示。啰嗦一点没关系总比在会议里翻车强。希望帮到你。本文还有配套的精品资源点击获取