sourcemap文件谁都能下，里面是55个还没上线的实验名

摘要：把131个海外电商站首页引用的JS和CSS逐个拉下来，检查有没有指向sourcemap的声明，再顺着声明去下载那份map。125个可测站里，85个（68.0%）声明了sourcemap，63个（50.4%）的map能被任何人完整下载，62个（49.6%）的map里内嵌着未经压缩的原始源码。这一轮总共下载到4475个自有源码文件、31.4MB代码。其中一个站的配置文件里列着55个实验名，另一个站的代码注释里写着内部Confluence的页面地址。

先说清楚一件事，免得后面读着别扭：本文里出现的所有内容，都是用普通浏览器访问公开地址就能看到的东西。没有绕过任何验证，没有猜测任何路径，全部来自各站自己在JS文件末尾写明的那一行声明。这件事的性质更接近“门开着”，而不是“撬锁”。

那行声明长这样，通常在压缩后的JS文件最后一行：

//# sourceMappingURL=main.8f3a2c.js.map

它是给浏览器开发者工具用的。压缩混淆之后的代码人读不了，出错时堆栈指向的是a.b.c(t,n)这种东西，没法调试。sourcemap就是一张对照表，把压缩后的每个位置映射回原始文件的行列号；如果这份map里还带着sourcesContent字段，那连原始源码本身都在里面，开发者工具可以直接把没压缩的代码显示出来。

这是一个非常好的设计。问题只有一个：浏览器只在开发者工具打开时才去请求那份map，但这不代表别人不能直接请求它。

什么是sourcemap，它为什么会跟着上线？

sourcemap不是某个框架的私有约定，它有正式规范，字段包括version、sources（原始文件路径清单）、names、mappings（位置映射）和可选的sourcesContent（原始源码全文）。前四个字段只暴露结构，最后一个字段暴露代码本身。

规范本身写得很清楚。Source Map格式规范把sourcesContent定义成可选字段，用途是让调试器在拿不到原始文件时也能显示源码；Chrome开发者工具关于source maps的文档则说明了加载时机——只有在开发者工具打开、并且启用了对应选项时，浏览器才会去请求那份map。两句话合起来就是问题的全部：字段是可选的，加载是有条件的，而文件本身的可访问性是无条件的。

它跟着上线，几乎总是因为同一个原因：默认值。现在主流的构建工具在生产模式下多半默认生成map，理由是Sentry、Datadog这类错误监控服务需要它才能把线上报错还原成可读堆栈。而生成之后要不要把map文件一起发到CDN，是另一个开关，两个开关分属不同的配置项，很多团队只知道前一个。

更常见的情况是根本没有人做过这个决定。脚手架建项目、CI跑构建、产物整个目录同步到对象存储——三步里没有哪一步会提醒你，.map文件和.js文件被一视同仁地当成了静态资源。这和支付页CSP那次实测里看到的模式一模一样：出问题的从来不是有人做了错误的决定，是没有人做过决定。

125个站里，有多少份能整份下载？

9月2日凌晨，我拿之前几批用的那份131个海外品牌电商站清单，对每个站的首页做了三步：取原始HTML、解析出前12个script和前4个stylesheet的地址、逐个下载并在文件尾部搜sourceMappingURL。找到声明的，再去下载那份map，解析JSON。

131个站取到125个（另外6个是403、超时或空壳页，全部从分母里剔除）。结果：

这里有一道尺子必须先说，否则中间那个数会虚高。第一版脚本的判据是“状态码200、并且能解析成带sources字段的JSON”，跑出来是71个站。抽查的时候发现不对：有些map只有29字节，内容是{"version":3,"sources":[],...}——一份合法但完全空的map。

16份空壳分布在13个站上，其中8个站只有空壳、没有任何真map。空壳分两种来源：

• 内联的29字节空map，写成data:application/json;base64,形式直接嵌在JS末尾，是压缩工具在关掉map内容后留下的空架子；
• 第三方服务给的105字节空map：aloyoga、framebridge、functionofbeauty、snowpeak四个站都引用了同一家同意管理服务的脚本，那家的osano.js.map是空的。

这个对照本身挺说明问题：第三方服务商知道要把map清空再发出来，而品牌自己的构建产物原样发了出去。把空壳剔掉之后，真正能拿到内容的是63个站，正好一半。

下载下来的是什么，有多重？

350份真map里，343份带sourcesContent，也就是说绝大多数能拿到map的站，拿到的是源码本身而不只是文件名清单。

数量上：sources条目一共8550条，其中3935条指向node_modules里的第三方包，4615条是各站自有代码，自有占54.0%。剔掉框架自带和第三方库之后，实际下载到的自有源码文件是4475个，未压缩总量31.4MB。这一轮为了拿到它们下载的map文件总体积是79.1MB。

单站排名前几位：

需要说明的是，这些数字只统计了首页引用的前12个脚本。一个电商站的商品页、结账页还会加载另一批bundle，各自也有自己的map。换句话说，上面的量是下限，不是全貌。

还有一个容易忽略的账：这些map文件占的是CDN存储和回源带宽。79.1MB是我一次抓取的量，如果有人写个脚本天天拉，成本落在站点这边——这类没人盯着的资源正是回源率优化时最容易漏掉的一块。当然，比起后面要说的内容，这点钱不算什么。

从文件路径能看出这个站是谁做的吗？

能，而且不用打开源码，光看sources里的路径就够了。

webpack打包出来的路径带项目名前缀，形如webpack://项目名/./相对路径。把8550条路径的前缀数一遍：

再看顶级目录名，指向的是技术栈：src 752条是通用写法；cartridges 518条是Salesforce Commerce Cloud的专有术语，只有那个平台把代码单元叫cartridge；shopify-theme 353条不用解释；gatsby 99条说明用的是Gatsby；_patterns 23条是Pattern Lab那套原子设计的目录约定。不需要指纹库，目录名自己会说话。

npm作用域这一层信息量更大。出现最多的是@sentry（488条）、@babel、@mui、@ark-ui、@swc、@aws-amplify，这些是公共包，说明用了什么监控、什么UI库、什么云。但里面混着几个不该在公共包列表里的名字：@rituals-packages（24条）、@rituals-digital（11条）、@lastbrand（4条）、@commercetools。前三个是私有作用域——公司内部的组件库名字。

@lastbrand这个尤其有意思，因为它出现在quince.com的产物里，而quince的品牌名不叫lastbrand。后面还会再遇到这个名字。

最直接的一条来自stokke.com。它的代码注释里有两个链接指向dept-de.atlassian.net，项目代号STOK。DEPT是一家国际数字代理商，-de是它的德国团队。也就是说，从sourcemap能读出这个站不是自己做的，是哪家代理商的哪个分部做的，用的什么项目代号。这类信息平时要靠案例页、领英和招聘启事去拼，现在写在代码里。

这一层对做竞品逆向分析的人来说是降维打击。传统方法靠技术栈检测扩展做指纹匹配，得到的是“可能用了React”这个级别的结论；而这里给的是仓库名、私有包名、代理商名和目录结构。

一家公司的实验清单长什么样？

quince.com的map里有一个叫src/config/statsig-experiments.config.ts的文件，还有一个src/experiments/configs/experiments.ts。这两个文件里一共列着55个实验名。

挑几组看：

把这55个名字排开，能读出的东西远超过一份技术清单：它是一份产品路线图。退货政策在试三种方案（免退货退款、二次退货收费、任意换货），结账和购物车在同时改版，个性化推荐已经到第三版，还在评估要不要在详情页隐藏某家分期支付服务。最后那条尤其敏感——那是商务关系，不是技术选型。

还有三组A/A测试值得单说。A/A测试是把用户随机分成两组、两组看到完全一样的页面，用来验证分流机制本身有没有偏差。做A/A测试说明这个团队对实验的严谨度有要求；而按全站、加拿大、美国切成三组分别做，说明他们怀疑不同地区的分流可能不一致。这是相当高水平的实验工程实践，只不过实践细节公开了。

顺带一提，实验平台是Statsig，从@statsig包（47条）和文件名都能确认。做A/B测试而不影响SEO那套判断的时候，通常最难拿到的就是同行到底在测什么——现在有一份现成的样本。

这份清单对同行的价值在于它是正在进行时。竞品分析里最难拿到的从来不是对方现在长什么样——那个打开页面就能看见；难的是对方接下来要变成什么样。一份实验配置文件把这个问题回答了：它列出的每一项都是还没有定论、正在用流量投票的事。算样本量那一步的功课，人家显然是做过的。

为什么一段代码注释比很多SEO文章还专业？

同一个站的另一个文件src/config/svd-flags.ts，7270字节，开头是一段很长的块注释。我读完之后愣了一会儿，因为那段话的专业程度超过了大多数公开的SEO文章。

大意是这样的（原文是英文，这里转述）：这是SVD这个项目的总开关，两个界面都受它控制；环境变量在除了生产和欧洲生产之外的所有环境里都是开的，生产环境默认关闭；各环境的值放在Helm的values文件和部署环境变量文件里。

然后是关键的那一段——为什么sitemap要单独一个开关：

渲染界面和sitemap的失效方式不一样。一张卡片渲染错了，只影响一个用户看到的一个页面，刷新一下就好了；而一份错的sitemap是递给谷歌的一份持久文档。

后面还跟着具体的数据依据：新版接口目前返回不全，比旧版少329个slug、少约5800个变体URL，所以sitemap必须能够继续留在旧版，等对齐了再逐个环境切换；如果两件事共用一个开关，就会被迫把两个本该分开的决定绑成一个决定。注释里还带着架构决策记录的编号和一个工单号STRFRNT-15810。

把这段话单独拎出来，它就是一篇很好的技术SEO短文。爬虫可见的文档和用户可见的页面，风险画像不同，因此灰度节奏必须分开——这个判断我在中文材料里很少看到有人讲得这么干净。它跟商品sitemap的分片策略是同一层的思考，只是人家把结论写在了代码里。顺带说一句，那个“少329个slug”的差额之所以要紧，是因为sitemap生成器给的合格判定只查格式，查不出“这份清单比上一份少了三百个地址”——那种缺口只能靠人自己对账。

这两段注释合起来还说明了另一件事：越是负责的团队，注释写得越详细，泄露出去的信息也就越有价值。写得潦草的代码泄露了也没人看得懂，写得清楚的代码泄露的是完整的判断过程。这是个挺别扭的结论，但它是真的。

另一个站bellroy.com的GoogleTagManager.ts里也有类似的东西。三条以XXX:开头的注释，讲的是数据层初始化的顺序陷阱：一堆东西依赖那个全局变量先存在，所以要在任何异步调用之前初始化它，但又有一批标签依赖第一个事件必须是客户数据；最后一条写着“极其重要：这个必须在交易对象之后push”，理由是标签管理器对每个数据层事件是先应用数据变更再触发标签，顺序错了就会拿到旧值。

做电商埋点的人看到这三条会心一笑——这是踩过坑才写得出来的话。它们本该躺在私有仓库里，现在躺在CDN上。

这也是这件事最微妙的地方：泄露出来的东西，有相当一部分并不“敏感”，而是“有价值”。没有密钥，没有token，没有用户数据。有的是判断、经验和还没公布的计划。

工单号和预发地址是怎么跟出来的？

把4475个自有源码文件全文扫一遍，找工单系统链接、非生产域名和内部邮箱，结果如下。

工单与文档系统，5个站21条：

thefarmersdog那一组特别直白，因为Shortcut的URL会把story标题拼进去。于是我们得到了这样几条：revise-new-chickpea-name（改鹰嘴豆配方的新名字）、spike-remove-useelementstate-hook（技术调研：移除某个hook）、uat-for-card-experiment-w-continue-button-round-2（卡片实验第二轮的验收测试）。产品命名、技术债清理、实验进度，三句话交代完了。

brooklinen那五条则勾出了内部文档的目录：他们把前端模块按Cart、Navigation、Nanobar、Spotlight Module这样组织，还专门有一个页面叫SEO Module。看得出SEO在这套系统里是一个独立模块，不是散落在各处的属性。

非生产环境域名，4个站：quince的api-staging、api-qa和mixpanel-dev三个子域（顺带暴露了真实主域名和品牌域名不是同一个）；buckmason的staging、cdn-staging，以及一个跨境服务商的跨境集成QA环境地址；brooklinen的一个开发用店铺地址；stokke的dev子域。

这一条我修过尺子。第一版正则匹配含dev、staging、qa、test的域名，跑出107条，一看全是developer.mozilla.org、developers.google.com、developer.salesforce.com——开发者文档站被dev这个词根全抓了进来。加上公共文档站排除名单之后，从107条降到17条、4个站。差点又把一份文档链接清单当成泄露事件来写。

另外两条尺子也值得记：一是首轮统计“构建机绝对路径”得到0条，我一度以为现代构建工具都把路径规范化了，后来发现是正则没剥掉webpack://前缀；修完之后确实发现了真实形态，是traeger.com产物里的file:///vercel/src/...——那是持续部署平台的构建目录。二是路径里含internal的条目有1198条，看着触目惊心，逐条核对发现1068条是某个基础库自己的internals/目录，跟“内部代码”毫无关系，真正有意义的只有几十条。

凡是特别大或者特别小的数字，先怀疑尺子。这一批我一共修了五次，每一次不修都会写出一个错的结论。

这到底算不算安全问题？

得分级说，一刀切成“严重漏洞”或者“无所谓”都不对。

不构成直接风险的：前端源码本身。压缩过的JS本来就在公网上，逻辑理论上都能逆向出来，sourcemap只是把成本从几小时降到几秒。前端里的公开标识（比如错误监控服务的DSN、公开的API key）设计上就是给浏览器用的，看到了也用不出花来。

构成信息面的：内部命名、工单号、非生产域名、组件库名、实验清单。它们单独看都不能直接利用，合起来能显著降低针对性攻击的准备成本——攻击者不再需要猜你的后台在哪、用什么框架、哪个接口刚改过。

真正危险的：如果源码里写死了后端密钥、内部接口的完整签名逻辑、或者鉴权绕过的路径，那就是实打实的漏洞。本次125个站里没有扫到这一类，但我的扫描只覆盖了首页的前12个脚本，不能作为任何站的安全结论。

非生产域名那一条要单独强调。预发环境通常防护更松、数据是生产库的副本、还常常忘了加noindex——预发站被搜索引擎收录这件事本身就是老问题了，而sourcemap相当于给这些地址做了一次定向广播。它跟子域名清点是配套的功课：一个从外部枚举，一个从代码里读，两边的名单对不上，说明有环境没进你的资产台账。

时机上这件事值得多说一句。8月28日，包括OpenAI、Anthropic、AWS、谷歌、微软、Cloudflare在内的一百多家机构联署了一封公开信，SEJ对这封信的解读里点出了一个关键判断：AI给攻击者的优势不是发明新漏洞，是让利用已有弱点的速度大幅提高——未打补丁的软件、过宽的权限、配置错误、技术债，这些东西一直都在，只是过去需要人力去找。

紧接着9月1日，WordPress宣布了一项核心安全计划，三件事之一就是用AI主动找漏洞、抢在研究者和攻击者之前。这两条新闻放在一起看，方向很清楚：“反正没人会去看”这个前提，正在失效。一份31MB的可读源码，过去需要有人有动机、有时间去读；现在读它的成本接近于零。

所以我的判断是：sourcemap公开在两年前是个卫生问题，现在是个风险管理问题。级别不高，但该处理了。技术债这类东西的麻烦之处一向不是单笔有多重，是它们会互相搭桥；而万一真出了事，被黑之后的搜索恢复要花的时间，跟当初改一行构建配置完全不成比例。

该关掉sourcemap，还是该换个关法？

直接关掉不是最优解，因为错误监控确实需要它。三种做法，按推荐顺序：

第一种，生成但不部署（推荐）。构建时照常生成map，在CI里把map上传给错误监控服务，然后从要发布的产物目录里删掉.map文件再同步到CDN。Sentry、Datadog这类服务都有官方的上传工具，这是设计好的路径。这样调试能力一点不损失，公网上什么都没有。

第一种做法还有一个附带好处：产物目录一旦被明确整理过，顺手就能把子资源完整性校验、压缩与混淆开关这些同属构建末端的事一起过一遍。它们出问题的原因是同一个，检查的时机也是同一个。

第二种，部署但挡住。如果流程上实在没法在同步前删，就在CDN或服务器层加一条规则，对.map结尾的请求返回403或404。这个办法的缺点是容易漏——比如内联的data:形式的map就挡不住，那种是直接嵌在JS里的。所以第二种只能算兜底。

第三种，只关内容不关映射。把sourcesContent字段去掉，保留mappings。这样堆栈还能还原到文件名和行号，但拿不到源码全文。多数构建工具都支持这个选项。适合那些必须让map公开可访问的场景。

还有一件顺手的事：顺便把生产环境的调试文件一起清一遍。本次实测里reebok.com加载的脚本文件名叫theme.dev.js——一个带.dev后缀的文件出现在生产首页上。这类东西和map是一个来源，都是“产物目录整个同步”留下的。

十分钟查清自己站上的暴露面

四步，不用装工具。

第一步，看有没有声明。控制台里跑：

const urls = [...document.querySelectorAll('script[src]')].map(s=>s.src)
  .concat([...document.querySelectorAll('link[rel=stylesheet]')].map(l=>l.href));
for (const u of urls) {
  const t = await (await fetch(u)).text();
  const m = t.match(/[#@]\s*sourceMappingURL=(\S+)/);
  if (m) console.log(u, '→', m[1].slice(0, 80));
}

第二步，看map能不能真拿到。把上一步打印出来的map地址在浏览器里直接打开。三种结果：404或403说明已经挡住了；打开是一份很小的JSON、sources是空数组，说明只有空壳，也没问题；如果能看到一长串文件路径，那就要看第三步。

第三步，看有没有源码。在那份JSON里搜sourcesContent。有这个字段就意味着源码全文在里面。这时候不要只看有没有，要看里面写了什么——重点搜这几个词：TODO、staging、atlassian、internal、experiment，再加上你们自己的工单前缀和内部域名。

顺便提一句，这四步跟查HTML注释里的内部痕迹是同一套动作的两半：一半查HTML层，一半查JS层。两边泄露的东西性质相同——都是内部记录跟着交付物一起出了门，只不过一个是人写的，一个是工具生成的。同一次上线检查里一起做掉最省事。

第四步，扩大范围。首页只是入口。商品页、结账页、账户页各自有不同的bundle，尤其结账相关的代码往往包含最多的业务逻辑和第三方集成。至少各抽一个页面重跑一遍前三步。

查出来有问题也别慌。这不是需要连夜修的那种事故，但值得在下一个迭代里排进去，而且改起来通常只是构建配置里的一两行。真正需要判断的只有一件：过去发出去的那些map已经被下载过多少次、被谁下载过，这个你查不到，也就意味着已经暴露的内容要按“已经泄露”来处理——如果里面有还没公布的产品计划，该重新评估的是发布节奏，不是删个文件就完事。

保哥前年帮一个客户查站点性能，顺手打开了他们的map，看到一个还在灰度的会员体系的完整前端逻辑，包括几档权益的判断条件。那套东西当时对外一个字都没提过。后来他们把map从CDN上撤了，但撤之前那个文件在公网上挂了七个月。七个月里有没有人拿走，谁也说不清。

最后回到开头那个比喻。门开着不等于有人进来偷东西，但一扇长期开着、而且自己都不知道开着的门，迟早会有人推。默认值会自己漂移，构建工具会升级，团队会换人，而.map文件安安静静躺在CDN上，既不报错也不告警。它是那种只有主动去看才会发现的问题，而主动去看的成本，是十分钟。

常见问题解答

sourcemap会不会影响SEO？

不会直接影响。搜索引擎不请求.map文件，它既不进索引也不影响渲染。间接影响有两个：一是map文件占CDN存储和带宽，量大时是成本问题不是排名问题；二是它把你的技术实现、实验计划和内部结构公开给了竞争对手，这属于竞争层面的损失，跟排名算法无关。判断要不要处理，别从SEO指标出发，从信息暴露出发。

我的站是Shopify/WordPress，也有这个问题吗？

有，但形态不同。本次实测里，Shopify主题的资源路径形如/cdn/shop/t/1256/assets/global.js，同样有站点声明了对应的map，只不过内容多是主题模板代码，泄露的是主题的实现而不是业务逻辑。WordPress的情况取决于主题和插件的构建方式，很多插件会把map一起打包发布。查法完全一样，就是上面那四步。

把.map文件设成404就够了吗？

大部分情况够，但有一个漏洞：内联map。有些构建工具会把整份map用base64编码直接嵌在JS文件末尾，写成sourceMappingURL=data:application/json;base64,...，这种没有独立文件，服务器规则挡不住。本次实测里就抓到若干这种形式（虽然内容是空的）。所以更可靠的做法还是在构建阶段控制，服务器规则当兜底。

关掉sourcemap之后，线上报错怎么排查？

用错误监控服务的上传机制。Sentry、Datadog这类服务都支持在CI里把map单独上传给它们，报错时由服务端做还原，浏览器侧不需要能访问map。这是标准做法，也是这些服务自己文档里推荐的路径。调试能力不受影响，只是map不再对公网开放。

为什么有的站声明了sourcemap却下载不到？

本次125个站里，声明了的有85个，能真正拿到的63个，差额22个。原因有三类：map文件确实没部署（返回404）、被服务器规则挡住（返回403）、或者返回的是首页HTML——那是单页应用的兜底路由，任何找不到的路径都返回首页。第三种最容易骗过检测脚本，因为状态码是200。判断的时候必须看正文首字节是不是那个左花括号，光看状态码会得到错的结论。

从sourcemap里能看出竞品在测什么，这算不算不正当？

访问公开地址不构成不正当，这和读对方的robots.txt、看对方的sitemap是同一类行为。需要注意边界的是后续动作：拿到的内容如果包含商业秘密（比如未公布的定价策略、合同关系），使用它就可能涉及法律和商业道德问题，各地法规也不一致。稳妥的做法是把它当成竞品技术分析的输入，别当成商业情报去用，更别公开转述对方还没发布的计划。

怎么知道我的map已经被人下载过？

查访问日志，按.map后缀过滤，看请求来源和频率。正常情况下这类请求应该极少（只有开发者打开调试工具时才产生），如果看到批量、规律性的抓取，那就是有人在系统性地收集。这一步值得纳入日志分析的常规项，和查伪造爬虫是同一套方法。

这次的比例能不能代表整个行业？

不能。样本是131个海外品牌电商站，其中能测的125个，偏向中大型DTC品牌，技术栈以Next.js和Shopify为主。技术团队规模更小的站，构建流程更简单，反而可能连map都不生成；而大型企业站的构建流程往往更规范，比例可能更低。这个50.4%只能说明“在这类站里，一半的map是公开的”，不要外推。

权威参考资料