简介：这份面向产品经理、交互设计师与前端开发者的 Chrome 扩展包，围绕 Axure 原型设计与网页界面走查场景，提供在浏览器内进行元素测量、区域截图、页面标注及原型对照的辅助能力，适合需要提升设计沟通与还原核对效率的初中级从业者。压缩包为 zip 格式，共 8 个文件，约 25KB，包含 3 个 PNG 图标资源、2 个 JavaScript 逻辑脚本、1 个 JSON 配置、1 个 HTML 入口页及 1 个 TXT 说明文件，体积轻量，便于了解 Chrome 扩展的基本组成与资源组织方式。已有 980 人学习或下载，说明其在原型设计辅助工具中具有一定关注度。读者可通过包内脚本、配置与页面文件梳理插件运行所需的结构，并结合图标与说明材料理解其功能边界，为网页元素量测、截图归档和设计稿比对提供可直接参考的轻量工具样本。

1. chrome 插件补的是哪条通道：Axure 原型白屏的真正原因

做原型的同行多半撞见过这个场面：Axure 里跑得好好的交互稿，导出成 HTML 发给对方，对方用 chrome 浏览器双击 index.html，页面白得干净，按钮点下去像石头。于是开始搜「chrome 谷歌浏览器 axure 插件」，搜出来的东西五花八门，有 crx、有 zip、有教你在地址栏敲参数的。这个插件真正干的事只有一件——在浏览器和本地原型文件之间补一条原本被协议掐断的通道。它适合两类人：一类是要把原型发给非技术同事看的产品经理，另一类是负责交付、得保证对方双击就能跑的设计支持岗。先把这条通道是什么搞清楚，后面装不上、装上了不干活、原型自己坏了这三类问题才分得开。

2. 三种失败现场：装不上、装上了不干活、原型本身坏了

绝大多数人卡住的地方不是「不会装」，而是没分清自己卡在哪一类。这三类失败的排查路径完全不同，混着查只会越查越乱。装不上是浏览器策略问题，装上了不干活是权限和清单问题，原型本身坏了则跟插件一点关系都没有。先把现场分类，再决定往哪个方向使劲。

2.1 安装期卡死：crx 拖不进浏览器、开发者模式被锁住

最典型的一幕是：拿到一个 crx 文件，拖到chrome://extensions页面上，弹出一句「无法从该网站添加应用、扩展程序和用户脚本」，或者拖进去转一圈什么都没发生。这不是文件坏了，是 Chrome 对非商店来源的 crx 安装做了限制，尤其是 Windows 环境，默认只放行商店来源。

另一类更隐蔽：页面右上角的「开发者模式」开关是灰的，鼠标放上去提示浏览器由所属组织管理。这是企业 IT 下发了策略，把开发者工具和扩展安装一起管住了。想确认是不是这个原因，地址栏敲chrome://policy，看列表里有没有和扩展安装来源、开发者工具可用性相关的条目。有的话，本机自己折腾是解不开的，得走 IT 申请，或者干脆换路线。

# 先确认拿到的 crx 是不是完整文件 ls -lh axure.crx file axure.crx # 正常输出里应该能看到 Zip archive 或 CRX 字样 # 如果 file 认不出来，大概率是下载中断，重新拿一份

这两条命令花不了十秒，但能省掉半小时的自我怀疑。file认不出格式的 crx，怎么装都装不上，问题根本不在浏览器。参数上没什么可调的，-lh只是让人眼看一下体积，几十 KB 的文件基本可以判定是下载页面返回的错误页而不是真扩展。

确认文件没问题、策略也没锁，那就别在拖拽上耗了。Chrome 从某个版本之后对拖拽安装的拦截越来越严，正确姿势是走「加载已解压的扩展程序」，也就是先把 crx 剥成目录，下一章细说。

2.2 运行期白屏：用 Network 面板把锅分给谁

插件装上了、状态是「已启用」，原型还是白屏，这时候别再猜，打开开发者工具看证据。顺序很重要：先看 Console，再看 Network。

Console 里要看的是第一条红色错误，不是最后一条。JS 报错有连锁反应，第一条才是根因，后面那一片往往是被带崩的。常见的几条长这样：

Network 面板的操作有个小细节：一定要勾上 Disable cache 再刷新，否则你看到的可能是上一次的缓存结果。刷新之后点一下 Status 列排序，把 404 和 failed 挑出来。再看 Protocol 列，是file还是http——这一列直接告诉你当前原型跑在哪种协议下，也就决定了后面该修哪一头。

如果 Network 里干干净净、全是 200，但页面就是不渲染，那就不是资源问题，是脚本执行顺序或者渲染容器的尺寸问题，往 Console 的报错和 Elements 面板的布局上查。

2.3 最小复现：拿一个空白原型当对照

这一步很多人跳过，但它能把排查范围砍掉一半。做法很简单：在 Axure 里新建一个空文件，只放一个按钮、加一个页面跳转，导出成 HTML，用完全相同的打开方式试一遍。

结果只有两种。空白原型也白屏，说明问题在环境——协议、插件、浏览器策略，跟你那个复杂原型没关系，按第 4 章的思路处理。空白原型跑得好好的，说明环境没问题，是你那份原型的资源引用、脚本或者页面体量出了状况。

顺带说一个二分法：原型页面多的时候，把页面删掉一半再导出，看还挂不挂。挂就继续删，不挂就把删掉的加回来。Axure 导出物里data/目录下是页面数据的集合，页面数量上去之后，单个数据文件会变得很大，某些低配机器上解析会超时，表现就是白屏但没有任何报错。这种玄学问题用二分法比看日志快得多。

3. 装 chrome 插件别只会双击：从 crx 剥壳到「加载已解压」的四步

拖拽安装这条路在新版 Chrome 上基本堵死了，正规做法是把 crx 还原成普通目录，再用「加载已解压的扩展程序」装进去。这一步听上去像黑魔法，其实 crx 就是一个前面加了几十字节头的 zip 包，把头切掉，剩下的就是标准压缩包。

3.1 剥壳：crx 就是一个前面加了头的 zip

不同代际的 crx 头部长度不一样，硬编码偏移量容易翻车，写个小脚本按头部里记录的字段长度动态跳过最稳。

import struct import sys def crx_to_zip(src: str, dst: str) -> None: with open(src, "rb") as f: data = f.read() if data[:4] != b"Cr24": # 有的分发渠道直接给的就是 zip，只是后缀名写成了 crx payload = data else: version = struct.unpack("<I", data[4:8])[0] if version == 2: pubkey_len = struct.unpack("<I", data[8:12])[0] sig_len = struct.unpack("<I", data[12:16])[0] offset = 16 + pubkey_len + sig_len elif version == 3: header_len = struct.unpack("<I", data[8:12])[0] offset = 12 + header_len else: raise ValueError(f"不认识的 crx 版本: {version}") payload = data[offset:] with open(dst, "wb") as f: f.write(payload) if __name__ == "__main__": crx_to_zip(sys.argv[1], sys.argv[2])

逻辑按字节走：前 4 个字节是魔数Cr24，紧跟着 4 个字节是版本号。版本 2 的头部结构是「公钥长度 + 签名长度 + 公钥 + 签名」，所以偏移量是 16 加上两段长度。版本 3 换成了「头部长度 + 头部内容」，偏移量是 12 加上头部长度。脚本里保留了「不是 crx 就当 zip 处理」的分支，因为有些渠道发出来的文件只是改了后缀，直接解压反而能用。

参数只有两个：sys.argv[1]是输入的 crx 路径，sys.argv[2]是输出的 zip 路径。跑完之后：

mkdir -p ~/axure-ext && cd ~/axure-ext python3 crx_strip.py axure.crx axure.zip unzip -o axure.zip -d ext ls ext

-o是覆盖已存在文件，-d指定解压到哪个目录。最后那句ls是关键一步，正确的输出里必须能看到manifest.json，如果没有，说明解压出来的层级多套了一层文件夹，装载的时候会报「清单文件缺失或不可读取」。遇到这种情况，进ext里再看一层，把真正包含manifest.json的那层目录路径记下来。

3.2 装目录：四步操作与两个必查开关

目录准备好了，接下来四步：

1. 地址栏输入chrome://extensions回车；
2. 页面右上角打开「开发者模式」；
3. 点左上角「加载已解压的扩展程序」，选中包含manifest.json的那一层目录；
4. 确认列表里出现新条目，状态显示为「已启用」。

四步做完不代表就能用了，还有两个开关必须回头确认。

第一个是扩展条目上的「允许访问文件网址」。在扩展卡片上点「详细信息」，往下翻能找到这个开关，默认是关的。它关着的时候，扩展在普通网页上活得好好的，一到file://页面就集体失声——这个坑极其隐蔽，因为扩展列表里一切正常，没有任何报错。

第二个是「开发者模式」本身。有些操作（比如重新加载扩展、查看错误）依赖它开着，关掉之后改过的文件不会自动生效，你会以为自己改错了，其实只是没重载。

3.3 核字段：manifest 里哪三行决定它能不能干活

一份能在本地原型页面上干活的清单文件，关键字段大致是这么个形状，核对的时候对着看：

{ "manifest_version": 3, "name": "prototype-bridge", "version": "1.0.0", "permissions": ["scripting", "activeTab"], "host_permissions": ["file:///*"], "content_scripts": [ { "matches": ["file:///*"], "js": ["content.js"], "run_at": "document_start", "all_frames": true } ], "web_accessible_resources": [ { "resources": ["bridge.js"], "matches": ["file:///*"] } ] }

三个关键点。manifest_version决定生死，新版 Chrome 只认 3，写 2 的扩展会被直接停用，列表里灰着，点也点不亮。host_permissions里的file:///*决定它能不能碰本地文件，只写了http://*/*的扩展在本地原型上等于不存在。content_scripts里的all_frames: true决定 iframe 里的子页面能不能被覆盖——Axure 原型里页面嵌套跳转很常见，这个字段少写，主页面正常、内嵌页面全废。

web_accessible_resources这一项容易被忽略，但它是让页面里的脚本能加载到扩展内部资源的通道，缺了它，注入的脚本可能连自己的依赖都拿不到。

3.4 怎么确认它真的在干活

装完之后别只看状态灯。三个验证动作按成本从低到高排：

第一，点扩展卡片上的「错误」按钮，有红字就是有问题，没有就是清单层面干净。第二，如果卡片上有「服务工作进程」或者「检查视图」的入口，点开能直接看到扩展自己的 Console，注入失败的报错都在这儿。第三，最直接的对照法——把扩展禁用，用同一个原型文件再打开一次，对比两次的表现差异。差异明显说明插件确实在起作用，两次表现一模一样说明它压根没插手。

4. 原理那一层：file:// 掐断了什么，插件又是怎么续上的

不搞清这一层，后面所有排查都是碰运气。为什么同一个原型文件，在本地双击打开就白屏，挂到服务器上就正常？为什么装了插件有时候好、有时候又不好？答案全在file://这个协议的特殊性上。

4.1 Axure 导出物的目录结构和加载链路

先看导出物长什么样。不同大版本会有差异，但主干结构大同小异：

加载链路大致是：浏览器打开入口页 → 加载resources/下的初始化脚本 → 脚本去data/目录拉取页面数据 → 解析成页面树 → 渲染进容器节点。关键在第三步，这一步通常是一次资源请求，而请求的协议决定了它能不能成功。

如果导出时选择了把数据内联进 HTML，那本地双击也能跑；如果导出物依赖外部数据文件，那在file://下必挂。这就是为什么有人说「我的原型本地打开没问题」，有人说「我的就是白屏」——不是谁的操作错了，是导出方式不一样。

4.2 file:// 协议的四条硬限制

第一条，每个本地文件都是一个独立源。在 Chrome 里，file://页面的 origin 是null，跟谁都不是同源，包括它自己目录下的兄弟文件。

第二条，对本地文件发起的 XHR 和 fetch 默认被拒。这条是白屏的头号元凶——页面渲染需要的那份数据文件就在隔壁，但浏览器不让拿。

第三条，iframe 加载本地文件时，父页面拿不到子页面的 document。Axure 原型里用 iframe 做页面内嵌的地方，跨页面通信会断掉，表现是某些联动交互失灵。

第四条，存储和字体这类边角也会遭殃。localStorage在file://下的行为在不同版本上并不一致，原型里用本地存储做的「记住状态」功能，可能在这个人机器上有效、换个人就失效。自定义字体文件因为跨域被拦，图标变成方块也是同一批原因。

4.3 插件补的是哪一环，以及不装插件的两条替代路

扩展之所以能绕开这些限制，靠的是它拿到的file:///*host 权限。有了这个权限，扩展可以在本地页面里注入脚本，把原本走 XHR 的数据读取换成走扩展内部的消息通道，等于在「页面」和「文件」之间架了一座桥。桥的两头它都有权限，所以不受同源策略管辖。

但如果扩展装不上、清单版本对不上、或者企业策略锁死了，还有两条替代路。

第一条，本地起一个 HTTP 服务。这是我最常用的方案，因为它不依赖任何扩展，跨机器、跨系统都能复现：

cd /path/to/prototype python3 -m http.server 8080 --bind 127.0.0.1

8080是端口，被占用就换一个；--bind 127.0.0.1只监听本机，别的机器访问不到，做内部演示足够。启动之后浏览器打开http://127.0.0.1:8080/index.html，这时候协议从file变成http，同源策略按正常规则走，那些被拦的请求全部放行。

第二条，给浏览器加启动参数，允许本地文件互相访问：

# macOS，先彻底退出 Chrome 再执行 "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \ --allow-file-access-from-files \ --user-data-dir=/tmp/chrome-proto-test

Windows 下换成chrome.exe --allow-file-access-from-files --user-data-dir=C:\tmp\chrome-proto-test。--user-data-dir单独指定一个配置目录，避免污染日常用的浏览器配置。

注意：这个参数是全局放开的，开了之后你打开的每一个本地 HTML 都能读本机文件，风险面不小。临时自查可以，交付给别人的机器上别这么干。

5. 避坑：五条血泪经验，每条都能对上一条真实报错

下面这五条，基本覆盖了我在交付原型时踩过的绝大部分坑。每一条都按「现象 → 原因 → 解决」写，遇到问题可以直接对号入座。

5.1 中文路径和空格：文件明明在，就是 404

现象：页面白屏，Network 面板里一片ERR_FILE_NOT_FOUND，可你去文件管理器里看，文件老老实实躺在那儿。

原因：file://的 URL 会把空格编码成%20，中文会被百分号编码。原型内部的脚本在拼相对路径时如果没做对应的编码处理，拼出来的地址和实际文件名对不上，浏览器自然找不到。

解决：原型所在的整条路径全用英文、数字和下划线，不带空格、不带中文。已经带了中文的，把目录改名之后重新打开。这一步在交付前就该做掉，别等到对方反馈白屏才想起来。

5.2 目录整体搬迁后相对路径全断

现象：在自己机器上跑得好好的，打包发出去，对方解压完就挂。

原因：只拷了入口 HTML，或者解压时把resources/、data/这几层单独挪了位置。导出物内部用的是相对路径，目录层级一变，所有引用同时失效。还有一种情况是压缩包里多套了一层文件夹，对方解压后路径多了一级。

解决：整个导出目录打成压缩包，解压后保持原始层级。交付前用一条命令核一下结构是否完整：

find . -maxdepth 2 -type d | sort find . -name "*.js" | wc -l

第一条看目录层级对不对，第二条数一下 js 文件数量，跟导出时的对比，数量明显偏少就说明有目录没拷全。

5.3 清单版本对不上，装了等于没装

现象：扩展列表里灰着，标注「已停用」，或者装载的时候直接报「清单文件缺失或不可读取」。

原因：老扩展用的是旧版清单规范，新版 Chrome 已经不再加载。老原型配新浏览器，这条路上撞墙的概率非常高。

解决：先看清单里的版本字段，是 2 就别折腾了，直接换路线。这也是我后来把本地 HTTP 服务当主力的原因——原型可能是几年前导出的，浏览器却一直在更新，插件这条路的有效期比想象中短。

5.4 同时装两个版本，扩展互相打架

现象：A 原型一切正常，B 原型点击没反应，而且只有同时开着两个扩展的时候才出现。

原因：两份扩展 ID 不同但功能重叠，同时启用时注入脚本会重复执行，事件被绑两次或者互相拦截，表现就是时灵时不灵。

解决：只留一个启用。chrome://extensions里每个卡片右下角都有开关，按需启停。做多项目交付的时候，我一般会为不同项目建不同的浏览器配置目录，物理隔离，比在同一个浏览器里切来切去省心。

5.5 改了原型，浏览器里还是旧的

现象：重新导出、覆盖了文件，浏览器刷新之后看到的还是上一版，改的地方全没生效。

原因：file://下的缓存策略和http不一样，磁盘缓存会留住旧的 js 文件，普通刷新不一定能穿透。

解决：开发者工具 Network 面板勾上 Disable cache，然后用Ctrl+Shift+R（macOS 上是Cmd+Shift+R）硬刷新。如果还是不行，把浏览器完全退出再开，别只关窗口。这一条在演示前十分钟发现，能把人急出一身汗。

6. 进阶：把原型交付压成一条能自检的流水线

交付这件事，出问题的从来不是技术难度，是流程里少了一道检查。我现在固定在做的是两件事：一份交付前必跑的自检表，和一个把「起服务 + 开页面」打包成一条命令的脚本。

6.1 交付前跑一遍的检查表

最后一条最容易被忽略，也最能暴露问题。你自己机器上装了扩展、开了各种参数，一切正常；对方机器干干净净，打开就是白屏。所以每次交付前我都会找一台「干净」的机器试一遍，试过才知道自己的原型到底依赖了多少环境。

6.2 一个脚本：查端口、起服务、开页面

把常用动作收进一个脚本，比每次手敲命令可靠得多：

#!/usr/bin/env bash set -euo pipefail PROTO_DIR="${1:?用法: ./serve_proto.sh <原型目录> [端口]}" PORT="${2:-8080}" if [ ! -f "$PROTO_DIR/index.html" ]; then echo "目录里找不到 index.html，确认选对了" exit 1 fi if command -v lsof >/dev/null 2>&1 && lsof -i ":$PORT" -sTCP:LISTEN >/dev/null 2>&1; then echo "端口 $PORT 被占用，换一个再试" exit 1 fi cd "$PROTO_DIR" python3 -m http.server "$PORT" --bind 127.0.0.1 & SERVER_PID=$! trap 'kill $SERVER_PID 2>/dev/null || true' EXIT sleep 1 URL="http://127.0.0.1:$PORT/index.html" if command -v open >/dev/null 2>&1; then open "$URL" else xdg-open "$URL" 2>/dev/null || echo "手动打开: $URL" fi wait "$SERVER_PID"

第一个参数是原型目录，必填；第二个是端口，不填默认 8080。脚本里做了三件事：校验入口文件存在、检查端口占用、起服务后自动打开页面。trap那一行保证按Ctrl+C退出时后台服务跟着关掉，不然端口会一直被占着，下次再跑就报冲突。

这套东西的价值不在脚本本身，在于它把「怎么打开原型」这件事从口头交代变成了可执行的步骤。对方收到的不是一句「你用浏览器打开就行」，而是一条命令。

血泪经验是有一回给外部同事演示，临开场发现对方机器上装不了扩展，我当场切到 HTTP 服务救场，从那以后每次交付前我都用一台干净机器完整走一遍上面那张表，不再赌对方的环境。希望帮到你。

本文还有配套的精品资源，点击获取