这个站要同时装下两类东西：轻的内容页和重的交互应用。
它们的诉求几乎是相反的。内容页要的是打开就出字、能被搜索引擎读懂、能长期沉淀；交互应用要的是大量 JavaScript、内部状态、可能还不小的体积。把两者揉进同一个构建产物，是我见过最常见的失败姿势。
四种做法
一、全部打包进主站。 作品作为主站的一个路由或组件。好处是体验无缝，坏处是依赖版本、全局样式、路由会互相打架——尤其是当你有五个以上作品，每个都有自己的技术栈时。
二、微前端。 用模块联邦之类的方案在运行时拼装。隔离性比第一种好，但复杂度和调试成本高得不成比例。为了一个个人站上这套，属于杀鸡用牛刀。
三、只放截图和外链。 最省事，但用户得跳出去才能用——在手机上这中间会流失掉相当一部分人。
四、iframe。 每个作品独立部署，主站只存元数据和一个地址。
我选了第四种。
它到底好在哪
样式和依赖彻底隔离。 作品用什么框架、什么 CSS 方案、什么版本的依赖，主站一概不管。反过来也一样。
崩溃不会传染。 某个作品内存泄漏把自己搞崩了，主站毫发无伤，用户关掉就行。
各自独立部署。 改一个作品的代码，不需要重新构建和发布主站。这一点在长期维护里省下的时间最多。
带宽可以让给真正需要的地方。 主站自己保持接近零 JavaScript，用户点“试玩”之前不需要为任何应用付出加载成本。
代价是什么
说实话，代价不是没有。
跨域通信要走 postMessage。 想同步主题、想根据内容调整高度，都得自己写消息协议。我目前只在文档里记了这个扩展点，还没实现——因为暂时用不上。
高度不能自适应。 跨域拿不到 iframe 内部文档的高度，所以只能约定固定的宽高比。对以画布、视频、全屏应用为主的作品来说，这反而不算限制。
要么接受隔离，要么接受耦合。 没有中间态。我选择接受隔离，因为个人站的长期维护成本主要来自“改一处崩三处”。
什么情况下我不推荐这么做
如果你的作品只有一两个、技术栈完全统一、并且希望它们和主站共享导航和状态，那打包进主站更合适。iframe 的价值在数量和异质性——作品越多、差异越大，它越划算。
对五个以上、技术栈各异的作品来说，我认为这是最省心的答案。