我打开一个后台管理页面，个网左边菜单栏，页上顶部导航条，框多否右侧工具栏，个网中间内容区还嵌着三个选项卡，页上选项卡里又套着两个表格面板。框多否鼠标滚轮滑下去，个网每层框架都在刷新，页上页面像俄罗斯套娃，框多否拆了一层还有一层。个网等我把所有数据核对完，页上浏览器已经吃掉我1.2GB内存，框多否风扇转得比我家洗衣机还响。个网

框架这东西，页上设计时觉得“多一层更清晰”，框多否用起来才知道是“多一层多一次等待”。有个同事做过统计，他经手的内部系统，页面平均嵌套四层div加两个iframe，首屏加载要三秒，操作一次响应要转两圈菊花。他后来把框架砍掉一半，页面轻了，用户反而说“这系统终于能用了”。

框架多的直接后果是事件冒泡混乱。你点一个按钮，理论上只触发一个click，实际却可能触发三层父容器的监听，每个监听里再调接口。数据刷新三次，界面闪三次，用户以为系统抽风。我见过最夸张的案例——某个电商后台的筛选区域，点一次“确定”，背后跑了七个AJAX请求，因为每个框架层都绑定了自己的查询逻辑。

更隐蔽的代价是维护成本。框架越多，命名空间越容易冲突。今天这个组件改了样式，明天那个模块的弹出层就错位。改一个底层框架的class名，上面三层全得跟着调，像抽积木，抽错一根就塌。有次我修一个bug，定位到第七层嵌套才发现是第三层的变量被第五层的赋值覆盖了，这种问题查起来，时间是按小时计的。

我自己写页面有个习惯：能平铺就不嵌套。一个页面最多三层结构——根容器、内容区、弹层。超过这个数，我会停下来问自己：这层真的有必要吗？有次为了省事给弹窗里又套了个弹窗，结果用户连续点两下，第二层弹窗定位全乱，直接跑出屏幕外。

话说回来，框架不是不能有，但要克制。就像抽屉，你有十个抽屉可以分类放东西，但每个抽屉里再分十个小格子，找东西就变成体力活了。网页是给人用的，不是给架构师炫技的。用户只看结果，不看你的树状图。

我见过一个极端的反例——某个数据可视化大屏，为了展示“高级感”，在SVG上又叠了canvas，canvas外再包一层绝对定位的div做tooltip，结果tooltip一多，整个页面卡得拖不动。后来改成纯SVG加单个浮层，流畅得飞起。

所以别迷信“分层清晰”。代码里分层是为了解耦，但页面结构分层越多，耦合反而越隐蔽。真正清晰的页面，是你一眼能看到内容，而不是先数清楚自己站在第几层。我宁愿多写几行平铺的代码，也不想让用户对着转圈圈发呆。