为何ui:include不适用于嵌入外部资源？聚焦安全疑问

嘿，这个问题问到点子上了！刚好BalusC的那个回答我印象很深，结合你关心的安全点，咱们来掰扯清楚为啥<ui:include>不是干这个活的料：

1. 它的设计初衷根本不是嵌入外部HTML #

<ui:include>是JSF Facelets专门用来复用内部模板片段的工具——比如你自己项目里的通用导航栏、页脚这些.xhtml片段，它是在服务器端编译阶段就把内容合并到主页面里，要求被包含的内容必须是Facelets兼容的（能被JSF引擎解析）。如果硬塞外部纯HTML进去，很可能因为标签不兼容、没有经过JSF生命周期处理，导致渲染乱码、标签失效甚至页面崩溃。

2. 安全风险：完全无隔离的执行上下文 #

这应该是你最关心的点！哪怕你们的内容都是自有，<ui:include>的合并方式意味着被包含的内容会完全继承主页面的执行权限：

• 如果被包含的HTML里不小心混入了恶意脚本（比如测试时的调试代码忘删了），它会直接在主页面的DOM环境下运行，能读取主页面的Cookie、操作所有DOM元素，甚至发起和主页面同域的敏感请求。
• 相比之下，<iframe>天生自带隔离性，你还能通过sandbox属性进一步限制它的权限（比如sandbox="allow-same-origin"只允许同域资源，或者sandbox="allow-scripts"控制脚本执行），哪怕自有内容出点小问题，也不会牵连主页面。

3. 灵活性和容错性差 #

<ui:include>是静态编译时处理的，没法根据用户请求动态切换要嵌入的外部资源（比如根据用户角色加载不同HTML）；而且如果外部资源加载失败，会直接导致整个主页面渲染出错。而<iframe>可以动态修改src属性实现动态加载，还能监听加载状态做错误处理，容错性强得多。

BalusC在那个回答里的核心观点就是：<ui:include>是为Facelets内部模板复用设计的，不是嵌入外部独立HTML的工具，强行使用会带来渲染和安全上的双重隐患，而<iframe>才是标准的外部内容嵌入方案，天然适配这种场景。

总结下来，哪怕你们的内容都是自有，<ui:include>的无隔离执行模式还是存在潜在风险，而<iframe>的隔离机制能更好地保障主页面的安全和稳定。

内容的提问来源于stack exchange，提问作者Clink