在Firefox和Chrome中，sourceURL的相对用法似乎有所不同-当某些工具在JS文件中生成//# sourceURL=...字符串（相对于放置它们的文件而言）时，Firefox将URL视为相对JS文件，而Chrome则将其视为相对于原始HTML文件。哪个是正确的，或者有一个更清晰的方法来说明这一点？
在此示例应用程序中，我尝试使用sourceURL允许将许多较小的文件合并为一个大文件，但仍允许浏览器知道应调用该较小的文件，并且{ {1}}，然后相对于原始文件指定源地图文件。
目录结构：
sourceMappingURL index.html
js/
all.js
uncompiled/
app.js
app.js.map
app.min.js
是加载index.html或js/all.js的最小页面。 js/uncompiled/app.min.js中没有其他JS（因为这是一个最小的示例），但是从理论上讲，这里可以有很多。该文件的目的只是将各种缩小的JS文件组合成一个更大的文件，而仍然允许开发人员查看原始代码，并相应地设置断点。
js/all.js的内容：
app.js然后，运行一个简单的minifier，用匹配的class App {
constructor(name) {
this.name = name;
}
sayHi() {
window.alert("Hello " + this.name);
}
}
new App("Colin").sayHi();
文件将其重建为app.min.js：
app.js.mapvar App=function(a){this.name=a};App.prototype.sayHi=function(){window.alert("Hello "+this.name)};(new App("Colin")).sayHi();
//# sourceMappingURL=app.js.map
最后，将缩小的输出包装在eval中，并将{
"version":3,
"file":"./app.min.js",
"lineCount":1,
"mappings":"AAAA,IAAMA,IAELC,QAAW,CAACC,CAAD,CAAO,CACjB,IAAAA,KAAA,CAAYA,CADK,CAIlB,IAAA,UAAA,MAAAC,CAAAA,QAAK,EAAG,CACPC,MAAAC,MAAA,CAAa,QAAb,CAAwB,IAAAH,KAAxB,CADO,CAKTC,EAAA,IAAIH,GAAJ,CAAQ,OAAR,CAAAG,OAAA;",
"sources":["app.js"],
"names":["App","constructor","name","sayHi","window","alert"]
}
参数添加到末尾（添加了换行符以提高可读性）：
sourceURL如果eval('var App=function(a){this.name=a};App.prototype.sayHi=function
(){window.alert("Hello "+this.name)};(new App("Colin")).sayHi();\n
//# sourceMappingURL=app.js.map\n//# sourceURL=uncompiled/app.min.js');
直接指向index.html，则Firefox和Chrome都正确理解app.js.map在同一目录中，并且在调试时应使用。但是，如果js/uncompiled/app.min.js指向index.html，则尽管两个浏览器都在单个文件中正确显示了js/all.js的内容，但只有Firefox才建立相对于eval的路径。
在此结构上使用all.js在Firefox中显示了以下结果：
python -m http.server另一方面，这是Chrome尝试的操作：
127.0.0.1 - - [14/Jun/2019 08:33:37] "GET / HTTP/1.1" 200 -
127.0.0.1 - - [14/Jun/2019 08:33:37] "GET /js/all.js HTTP/1.1" 200 -
127.0.0.1 - - [14/Jun/2019 08:33:38] code 404, message File not found
127.0.0.1 - - [14/Jun/2019 08:33:38] "GET /favicon.ico HTTP/1.1" 404 -
127.0.0.1 - - [14/Jun/2019 08:33:41] "GET /js/uncompiled/app.js.map HTTP/1.1" 200 -
127.0.0.1 - - [14/Jun/2019 08:33:41] "GET /js/uncompiled/app.js HTTP/1.1" 200 -
Chrome似乎假设127.0.0.1 - - [14/Jun/2019 08:34:22] "GET / HTTP/1.1" 200 -
127.0.0.1 - - [14/Jun/2019 08:34:22] "GET /js/all.js HTTP/1.1" 200 -
127.0.0.1 - - [14/Jun/2019 08:34:22] code 404, message File not found
127.0.0.1 - - [14/Jun/2019 08:34:22] "GET /uncompiled/app.js.map HTTP/1.1" 404 -
127.0.0.1 - - [14/Jun/2019 08:34:23] code 404, message File not found
127.0.0.1 - - [14/Jun/2019 08:34:23] "GET /favicon.ico HTTP/1.1" 404 -
中的sourceURL相对于js/app.js，而Firefox（根据我的观点，正确地）将其解释为相对于{{1} }。我建议Firefox是正确的，因为它允许任何HTML文件在任何路径下都包含该JS，并且仍然可以正确加载源地图。
示例源，包括两个位于不同相对路径的html文件：https://github.com/niloc132/sourceurl-and-sourcemapping-url-relative-paths
答案 0 :(得分：0)
根据规范（或位于https://sourcemaps.info/spec.html的副本）：
如果源映射URL不是绝对的，则它相对于生成的代码的“源起源”。源起点是由以下情况之一确定的：
- 如果生成的源未与具有“ src”属性的脚本元素相关联，并且在生成的代码中存在
//# sourceURL注释，则应使用该注释来确定源的来源。注意：以前，这是“ // @ sourceURL”，就像“ // @ sourceMappingURL”一样，可以接受这两者，但是//＃是首选。- 如果生成的代码与script元素相关联，并且script元素具有“ src”属性，则script元素的“ src”属性将作为源来源。
- 如果生成的代码与script元素相关联，并且script元素不具有“ src”属性，则源原点将是页面的原点。
- 如果使用
eval()函数或通过new Function()将生成的代码评估为字符串，则源来源将是页面的来源。
在js/all.js的情况下，它是最后一种情况：源原点将是页面的原点。因此，即使看起来似乎违反直觉，Chrome似乎仍遵循该规范。