xml关联xsl的声明必须是，位于xml声明后、根元素前且仅一条；href为相对xml文件路径，type须为text/xsl；本地file://协议下chrome禁用xslt，现代浏览器普遍弱化支持，推荐js或服务端转换。
XML文件里怎么写关联XSL的声明
必须放在XML文档开头、根元素之前，且只能有一条，否则浏览器会忽略后续的。声明不是XML标签，而是处理指令（PI），格式非常固定。
- 语法是
<?xml-stylesheet type="text/xsl" href="style.xsl"?>，type必须为text/xsl（IE/Edge旧版只认这个；现代浏览器也支持application/xml+xslt，但兼容性差，不建议） -
href是相对路径，基于XML文件所在位置解析，不是浏览器当前URL路径。比如XML在/data/feed.xml，XSL在/css/transform.xsl，就得写href="../css/transform.xsl" - 这条指令必须紧贴XML声明之后（即
<?xml version="1.0"?>下一行），中间不能有空行或注释，否则部分浏览器（特别是Safari）会失效
为什么浏览器没加载XSL，或者报错“Stylesheet not found”
90% 是路径或MIME类型问题，和XSL语法关系不大。浏览器加载XSL时走的是独立HTTP请求，和XML本身分开校验。
- 检查浏览器开发者工具的 Network 面板，看
href对应的XSL文件是否返回 404 或 403 —— 常见于静态服务器未配置XSL MIME类型（需返回text/xsl或application/xml+xslt） - 本地双击打开XML文件（
file://协议）时，Chrome 会直接禁止加载XSL（CORS限制），Firefox 和 Safari 表现不一；必须用本地服务器（如python3 -m http.server）才能正常测试 - XSL文件里如果用了
xsl:import或xsl:include，其href也是相对XML文件位置，不是相对XSL文件位置 —— 这点极易搞错
XML + XSL 在不同浏览器里的行为差异
不是所有浏览器都把XSLT当“默认渲染引擎”，尤其新版本越来越弱化支持。
- Chrome 自 100 版本起已完全移除内置XSLT处理器，打开带
xml-stylesheet的XML只会显示原始树状结构（除非装了扩展或用JS手动调用XSLTProcessor） - Firefox 仍原生支持，但要求XSL中不能有
<script></script>（已被禁用），且xsl:output method设为html时，输出不会自动补全，得自己写 - Edge（Chromium内核）和 Chrome 行为一致；Safari 支持有限，对XPath 2.0+ 函数（如
format-date()）直接报错
想稳妥让XML“看起来像网页”，还有没有更可控的办法
纯靠浏览器内置XSLT已经不可靠，真要交付，得主动接管转换过程。
- 用JavaScript加载XML和XSL，通过
DOMParser和XSLTProcessor手动执行转换，再插入到页面 —— 这样绕过浏览器策略，也便于错误捕获 - 服务端转换更稳：用Node.js（
xslt包）、Python（lxml）、Java（javax.xml.transform）提前转成HTML，XML只作数据源 - 如果只是展示结构化数据，直接用JS解析XML字符串（
new DOMParser().parseFromString()），用模板字符串生成HTML，比折腾XSLT简单得多，也更容易调试
