企业官网建设流程全解析

1. 为什么AI病历生成会撞上样式冲突

先说一个真实场景。医院的电子病历系统页面里，AI正在自动生成一段病史记录。内科医生点了“生成”按钮，几秒钟后，一段结构化病历出现在页面上——标题字号比正文还小，表格边框消失得干干净净，按钮变成了浏览器默认的灰色方块，字体颜色一会蓝一会黑。这不是AI生成内容的质量问题，是样式冲突。

我在实际项目里碰到过不止一次，而且这类问题有一个共性：AI病历模块一定是“外来户”。医院的信息系统通常由HIS（医院信息系统）、EMR（电子病历）、LIS（检验系统）、PACS（影像系统）等多厂商系统拼装而成。各家系统的前端技术栈五花八门：有的还在用JQuery时代的模板引擎，有的用Vue2，有的已经上了Vue3，还有一部分是React。你新接进来的AI病历生成器，无论是作为插件还是独立页面嵌入，都得跟这些“老前辈”在同一个页面里共存。

最典型、最容易踩中的三个冲突场景，我挨个说。

第一个是全局Reset样式互相覆盖。老系统为了兼容自己的老页面，通常有一套自定义的全局Reset，比如给所有div设置margin: 0、给所有h系列标题设置固定的line-height、给所有button设置background: none。新的UI组件库（Element Plus、Ant Design）也有自己的Reset逻辑。两边一叠加，谁后加载谁说了算，结果就是AI生成的内容里，标题、段落、按钮的样式完全没法预料。

第二个是UI库之间的class命名污染。很多系统里同时存在Element UI和Ant Design——一个页面里因为历史原因两种组件库都会被按需引入。.el-button的样式和.ant-btn的样式对同一个按钮都会生效，padding、border-radius、字体大小会互相覆盖，最终渲染效果取决于样式表的加载顺序。AI病历里如果同时用到了两种组件库的组件，出来的界面基本就是“混血儿”，没人能预测它长什么样。

第三个是作用域穿透。Vue的scoped样式、第三方组件库的内部样式、宿主系统的全局样式三者在同一条CSS规则链路里绞在一起。尤其是AI病历往往通过innerHTML动态插入富文本内容，这些内容的类名是AI模板里写死的，根本不受你项目的scoped约束。实测下来，AI流式输出一段带Markdown渲染的诊疗建议，插到页面上之后，h3字号被宿主的全局样式放大到接近body的两倍，pre代码块背景色直接丢失，table边框成了虚线——看着就像一份病历被丢进了格式清洗机。

你可能会问：既然是“外来户”，干嘛不把模块做成独立页面，不和宿主页面搅在一起？这是最朴素、最正确的思路，而它的技术实现方式，就是本文标题说的“一个iframe”。iframe这个东西在Web开发里一直被看作“老古董”“不规范”“性能杀手”，但在我处理AI病历生成的样式冲突这个问题时，它反而是最优雅、成本最低的解法。

2. 我走过的弯路：那些“过度设计”的隔离方案

在最终选择iframe之前，我先后尝试了三种主流的样式隔离方案，每个都是正经技术，每个都在实际项目里碰了壁。写出来供大家参考，不是劝大家不要用，而是想说清楚为什么在“AI病历生成”这个具体场景里，它们都显得过度设计了。

2.1 CSS Modules加BEM命名约定

第一版方案是最“规范”的：项目内部全部使用CSS Modules，每个组件类名走BEM命名约定，比如ai-report__title、ai-report__table--bordered。这样做的好处是团队自有的代码确实干净了，但问题在于——AI病历的内容不是我们项目自己的组件，而是动态拼接出来的HTML字符串。

AI大模型输出的markdown内容，需要前端模板去渲染成带类名的HTML。类名可以自己定义，但这份HTML插入到宿主页面后，宿主页面的全局样式压根不管你什么BEM不BEM，只要有选择器能匹配上，它就会强制覆盖。比如宿主给p标签设置了font-size: 14px !important，你的AI报告里所有的段落文字都被锁死在这个字号，CSS Modules的类名作用域根本挡不住。

更难受的是，第三方组件库的样式不是CSS Modules。Element Plus、Ant Design这些库，要么用全局class，要么用CSS变量，要么两者兼顾。AI病历里用的提示条、时间线、折叠面板，样式照样被宿主全局样式干扰。这套方案跑了一个迭代，代码规整度是不错，但样式冲突率基本没降。

2.2 postcss插件给全量样式加前缀

第一次吃瘪之后，我转向了“全量加前缀”的思路。就是用postcss-prefix-selector这类构建期插件，把项目里所有的class选择器自动加上前缀，比如.ai-bridge-。这样UI组件库生成的.el-button会变成.ai-bridge-.el-button，理论上宿主页面的全局样式就匹配不上了。

听起来无懈可击，落地的时候全是坑。第一，UI组件库的样式需要单独处理。Element Plus源码里有大量嵌套选择器、属性选择器、伪类选择器，postcss插件在转换的时候会漏掉一部分，或者把不该加前缀的地方也加上，编译产物经常出问题。第二，scoped样式里的:deep()选择器会被postcss插件转得一团乱麻，你得手动写一堆:deep(.el-button)去兼容。第三，你引入的第三方插件里的内联样式、行内style、动态生成的style标签，都不受构建期插件控制，照样冲突。

这个方案折腾了两个星期，build配置越改越复杂，样式冲突率降了一些，但维护成本高得离谱。每次升级组件库都要回来重新调一遍postcss插件，遇到动态生成的样式还是没辙。

2.3 尝试引入Shadow DOM的教训

前两个方案效果都一般，我一度把希望寄托在Shadow DOM上。理论上Shadow DOM是浏览器原生的样式隔离机制，组件内部的样式和外部样式是一堵真正的“防火墙”。AI病历模块做成一个Web Component，挂到宿主页面里，样式冲突问题应该从根上解决。

真实项目里用它做业务系统，会遇到几个让人头大的问题。弹窗组件（比如el-dialog）默认挂在body节点下，不在Shadow树内，它的样式依旧被宿主全局样式影响。表单控件、下拉选择器的弹出层是基于body定位的，z-index、fixed定位在Shadow DOM的隔离环境下会失灵，弹层不是被遮挡就是位置偏移。还有兼容性——虽然现代浏览器都支持，但医院业务系统里经常有用户用旧版Edge和国产浏览器内核，Shadow DOM的行为差异很容易导致线上问题。

更关键的是团队的成本。我当时的项目组没人系统研究过Shadow DOM的调试方式，遇到问题需要在Chrome DevTools里切换Shadow树查看样式，排查效率低了一大截。为了一小段AI病历展示，把整条链路的复杂度拉高了好几个档位，这已经不是“解决问题”，而是“制造新问题”了。

2.4 反思：我们到底在为什么买单

三个方案逐一失败后，我回过头来想了一下。AI病历生成这个需求的本质，是“一段外部生成的富文本内容，要在宿主系统里展示，并且样式需要稳定可控”。这个需求不像复杂组件库那样需要高密度的数据交互，它的大部分内容都是展示型的，医生操作也主要是“生成、查看、修改、保存”。

那么，为什么非要用CSS隔离技术去硬刚宿主页面呢？为什么不干脆让这段内容“活在自己的世界里”？一个朴素到可能被所有人忽略的方案——iframe——能真正做到这件事。

3. 一个iframe带来的“简单之美”

iframe方案的思路特别直白：把AI病历模块做成一个独立的HTML页面，宿主系统里只需要留一个div容器，用iframe嵌进去。因为iframe加载的是独立文档，它的CSS和宿主页面的CSS之间是浏览器级别的硬隔离——宿主页面所有的全局样式、Reset、UI库样式，都影响不到iframe内部的东西。反之亦然，iframe内部的样式也不会去污染宿主页面。

我认为这个方案的“简单之美”，在于它把复杂问题转化成了标准问题，而不是继续堆叠技术去解决复杂问题。你不需要约定命名规范，不需要给构建期加插件，不需要处理Shadow DOM的兼容性。宿主页面的改动量，小到一个div加一段初始化JS。

不过，简单不等于没有技术含量。要用好iframe，有几个关键点必须做对。

3.1 整体设计：宿主页面只做“容器”

我们先看宿主页面的改造。原来AI病历模块直接渲染在页面上，改造后只需要一个容器div：

<div id="ai-report-container"></div>

然后在宿主脚本里初始化iframe：

function initAIReport() { const container = document.getElementById('ai-report-container'); if (!container) return; // 创建iframe，加载独立的AI病历页面 const iframe = document.createElement('iframe'); iframe.src = '/ai-report/index.html'; iframe.id = 'ai-report-frame'; iframe.style.width = '100%'; iframe.style.border = 'none'; // 关键：禁止iframe自身出现滚动条，滚动逻辑交给内部页面 iframe.setAttribute('scrolling', 'no'); iframe.style.overflow = 'hidden'; container.appendChild(iframe); // 监听iframe内部发来的消息 window.addEventListener('message', handleMessage); }

这段代码看着简单，但背后有几十行细节要处理。第一个细节是iframe的宽度：宿主页面容器宽度变化时，iframe要跟着变，所以width用100%，同时iframe内部页面要设置同样的自适应布局。第二个细节是高度：因为scrolling关掉了，iframe的高度必须跟内部内容高度一致，否则内部内容就会被裁切，或者外边出现多余的空白。这就是所有iframe方案都要面对的“高度自适应”问题，后面专门展开讲。

3.2 用postMessage打通内外通信

如果只是静态展示，iframe就够了。但AI病历生成不是一个静态页面，它需要接收患者信息、拉取病历初稿、传递AI生成参数、上报生成状态。宿主页面和iframe内部页面之间，需要一套双向通信机制。

标准做法是postMessage。父页面往iframe内部发消息，用iframe.contentWindow.postMessage；iframe内部往父页面发消息，用window.parent.postMessage。关键是消息协议要设计得足够清晰，保证两边不会因为消息混乱而出bug。

我这里设计了一套简单的消息协议：

// iframe内部页面发送消息给父页面 window.parent.postMessage({ type: 'heightChange', // 消息类型 payload: { height: document.documentElement.scrollHeight } }, '*');

父页面监听：

function handleMessage(event) { // 安全校验：只接受来自我们自己iframe页面的消息 if (!event.source || event.source !== document.getElementById('ai-report-frame').contentWindow) { return; } const data = event.data; if (!data || !data.type) return; switch (data.type) { case 'heightChange': updateIframeHeight(data.payload.height); break; case 'reportReady': hideSkeleton(); break; case 'action': handleAction(data.payload); break; default: break; } }

这里有一个安全细节：postMessage的targetOrigin不要用'*'，要写具体的域名。虽然AI病历显示的是医院内网数据，但现代浏览器对postMessage的校验是标准的。如果targetOrigin写'*'，任何其他页面都能往你的iframe里发消息，可能造成信息泄露或逻辑注入。我建议生产环境中targetOrigin写具体的协议加域名（比如https://emr.hospital.com），同时父页面监听消息时校验event.source是不是自己创建的iframe窗口。这两个校验做好，通信就靠谱了。

3.3 高度自适应：隐藏滚动条的关键操作

iframe方案最烦人的问题，就是内容高度变化后，外层高度不跟着变。AI病历是流式输出的，医生每点一次“继续生成”，内容就会增加几百行，iframe高度要实时变化。如果这里处理不好，就会出现两层滚动条：iframe内部一个，宿主页面又一个，体验极差。

我的做法是：iframe内部用MutationObserver监听DOM变化，高度变化后通过postMessage通知父页面更新iframe高度。具体代码如下：

// iframe内部：监听内容变化并上报高度 function watchHeight() { let lastHeight = 0; let ticking = false; function reportHeight() { const height = document.documentElement.scrollHeight; if (Math.abs(height - lastHeight) > 1) { lastHeight = height; window.parent.postMessage({ type: 'heightChange', payload: { height } }, 'https://emr.hospital.com'); } ticking = false; } const observer = new MutationObserver(() => { if (!ticking) { ticking = true; // 用requestAnimationFrame做节流，避免频繁触发布局抖动 window.requestAnimationFrame(reportHeight); } }); observer.observe(document.body, { childList: true, subtree: true, characterData: true }); }

这里有两个关键优化。第一，MutationObserver要同时监听childList、subtree和characterData，因为AI病历的流式输出是不断往DOM树里插入文本节点的，只监听childList会漏掉纯文本变化。第二，requestAnimationFrame的节流很重要。AI流式输出的频率非常高，如果每次都直接postMessage，父页面会频繁修改iframe高度，导致整个宿主页面不断重排，CPU占用率会飙上去。

父页面收到消息后，也不能直接设置iframe高度就完事。我给高度过渡加了200ms的CSS动画，否则高度突然从500px跳到1500px，页面会“弹跳”，眼睛看着很难受：

#ai-report-frame { transition: height 0.2s ease; }

这样就实现了“内容长多高，iframe就长多高”，并且外层滚动条被隐藏，只有iframe内部的滚动条在工作，整个交互顺滑等同于原生页面。

3.4 后顾无忧：隐藏滚动条、边框和多余空白

除了高度自适应，还有一些肉眼可见的“细节边角”要处理。iframe默认自带边框和内边距，在不同浏览器里会显示成灰色细线，视觉上比较突兀。所以样式上一定要设置border: none，同时把iframe内部页面的margin和padding清干净。宿主页面的容器div也不要有不必要的padding，否则内容会缩得更窄。

滚动条的处理还有一点：光靠iframe的scrolling="no"在Firefox某些版本下不够，最好再叠加一层overflow: hidden。同时iframe内部的body要设置overflow-x: hidden，防止AI生成的宽表格在页面里撑出横向滚动条。这些小细节看着不起眼，但在医院大屏和医生工作站上，任何多余的滚动条都会让医生觉得这系统很“业余”。

4. 实操细节与踩坑记录

方案定型之后，我在真实环境里又跑了一个多月，踩了不少坑。这些经验比较散，但都特别实用，放在一起方便查。

4.1 首次加载性能：iframe不是白屏的借口

iframe方案最常见的抱怨是白屏。这确实是个客观问题：iframe就是加载了一个完整页面，CSS、JS、组件库都要重新加载一次，比直接在宿主页面里渲染要慢。

但这个问题是可以用工程手段缓解的，不是无解。我实际的处理方式有三条线并行。第一，父页面在初始化时先显示一个骨架屏（占位loading），告诉医生“AI模块正在启动”，避免出现空白。第二，iframe内部页面做资源预加载，把AI病历模块依赖的CSS和JS放在preload标签里，让浏览器提前解析。第三，切换患者时不要销毁iframe实例，只更新内部数据。比如医生从“患者A”切到“患者B”，iframe保持挂载，内部通过postMessage接收新的patientId，重新拉取病历初稿。这样首次加载的几十毫秒成本就被摊薄了，后续切换几乎无感。

实测下来，医院内网的局域网环境下，iframe页面首屏加载在1.5秒左右，加上骨架屏的过渡，医生基本感知不到白屏。相比用Shadow DOM或CSS Modules的那版方案，这里体验没有变差，反而因为隔离干净了，页面稳定很多。

4.2 消息风暴：AI流式输出的高频更新

AI病历生成是流式的，token一个接一个地蹦出来。如果每次token变化都触发MutationObserver，然后都上报一次高度，消息频率会非常夸张。我做过一次实际压测，流式生成一份3000字的病程记录，如果不开节流，postMessage的调用次数能达到上千次。

节流方案上面提到了，用requestAnimationFrame加一个“触发后置”的标记。但仅靠rAF还不够。我在消息协议里加了一个阈值：如果高度变化小于5px，直接不上报。这个阈值对用户体验几乎没有影响，但消息量能砍掉约70%。实际场景里，一次点击“生成”按钮，从AI开始输出到输出完毕，高度上报次数控制在20次以内，父页面的布局重排压力几乎可以忽略。

还有一类消息风暴来自“保存成功”提示。AI病历编辑后点击保存，iframe内部会弹出成功提示，同时给父页面发一条action消息通知刷新左侧患者列表。这个还好，频率不高。真正要注意的是不要把错误日志也通过postMessage高频上报，否则父页面的console会被刷爆，调试都困难。实际的错误日志我全部留在iframe内部，只有会影响宿主页面逻辑的严重错误才上报。

4.3 打印场景：iframe内容无法直接打印

业务系统里有个雷打不动的需求——病历打印。直接window.print()打印宿主页面，iframe里的内容是打不出来的，因为打印引擎只打印当前document的内容。

这个问题我最后用“内容克隆”解决：当用户点击“打印病历”时，宿主页面通过postMessage通知iframe内部，把当前AI病历的HTML内容提取出来发给父页面；父页面把这份HTML插入到一个隐藏的打印容器里，然后调用window.print()。打印时只显示这个打印容器，其他部分用CSS的@media print隐藏。

这里有个坑要注意：克隆过来的HTML里如果有图片，图片的跨域问题会导致打印时图片不显示。医院内网系统通常是同一个域名部署，一般问题不大。如果是跨域的图片，建议在iframe内部把所有图片转为base64再发送，虽然文件大一点，但打印稳定性直接拉满。

4.4 常见问题速查表

这些问题的共同核心，都在于“内外部之间信息同步”这件事。只要消息协议设计得足够完善，边界情况考虑得足够全面，iframe方案在业务系统里是非常可靠的。

4.5 Android端的移动端适配

医院也不是只有电脑。查房时医生拿平板和手机看病历，触屏设备的iframe行为坑也不少。Android端，iframe的滚轮事件默认被内部页面吃掉，导致宿主页面无法滚动。另外软键盘弹起时，iframe的高度会被挤压，MutationObserver会误报高度变化，产生跳动。

我的处理是：识别到移动端浏览器（通过UA判断），父页面监听到iframe的wheel事件时，手动判断iframe内部是否已经滚动到底部，如果到底了，就把滚轮事件交给宿主页面处理。软键盘问题，则是监听window.visualViewport的resize事件，在软键盘弹出时暂停高度上报，收起后再恢复。这套逻辑在iOS上基本不兼容，但移动端用iframe的场景还是少，PC端为核心，移动端做到“能用，不弹”就算满意了。

5. 什么时候该用iframe，什么时候不该用

一个iframe解决了AI病历的样式冲突，但这不代表iframe是万能的。技术上没有银弹，选型的关键是匹配场景。

适合iframe的场景，有一些共性：内容相对独立，和宿主页面之间主要是数据交互而不是UI深度融合；宿主系统技术栈老旧或复杂，隔离成本很高；不需要考虑搜索引擎优化（因为登录后系统本来就不会被索引）；内外系统分属不同团队维护，iframe能让各自独立发布、互不阻塞。

不适合的场景也有，典型的就是需要和主页面深度交互的模块。比如拖拽合并元素、右键菜单需要和宿主页面融合、全局快捷键要统一处理，这类场景iframe处理事件和焦点管理的复杂度会非常高。还有对性能和SEO极其敏感的公网页面，iframe的加载开销和多document结构会带来明显劣势。另外，像实时协同编辑这类需要多人同时操作同一份文档的场景，iframe内部是独立的document，协同引擎要做很多额外的通信协议设计，远不如直接工作在宿主页面上方便。

AI病历这个需求之所以很适合iframe，是因为它本质上就是“一个独立内容在另一个系统里被查看和编辑”。展示的独立性天然适合隔离，而数据交互恰好可以建模成一套消息协议。这就像外科手术里，能选微创绝不开大切口——但你不能因此说微创永远比开腹好，得看病情。

如果后续模块数量多了，这套方案也能往两个方向演进。一是把iframe通信封装成一套简单的SDK，比如window.AIReportBridge，内部统一处理postMessage、高度自适应、消息协议版本。新增业务模块时只需要引入SDK，无需每个模块重复实现。二是在消息协议里加version字段，方便以后多个业务模块共存时做消息路由。这套设计放在微前端体系里也是兼容的——微前端的核心思路之一就是应用隔离，iframe天然就是一种隔离度最高的微前端实现形态。

我个人在实际操作中的体会是：很多样式冲突的“烂摊子”，根本原因不是技术不够强，而是方案选型在“复杂度”和“需求真实难度”之间没对齐。如果一开始就冷静评估AI病历模块的边界，直接用一个iframe去承接，那些CSS Modules、postcss插件、Shadow DOM折腾出来的时间，早就足够把消息协议打磨得很完善了。技术选型这件事，很多时候不是越高级越好，而是“刚好够用，还留有余地”才是最好的。