1. 为什么非要给区块加上高度设置这周发布的新版本里最重要的更新其实只有一条区块支持高度设置了。这句话写在更新日志里就一行但如果你是用可视化区块拖拽搭页面的那批人应该立刻能感觉到——之前的页面区块高度基本是“内容说了算”内容多高区块就多高想让一个区块固定成某个高度要么靠占位图硬撑要么靠加一堆空行折腾半天还经常塌。这次更新之后区块可以自定义固定高度、最小高度和自适应高度覆盖了日常搭建页面时九成以上的排版需求。说实话这个功能我惦记了很久。进一步讲它补充的其实是页面布局里很要命的一块“自由度”。以往在页面编辑器里宽度、间距、对齐方式都能调唯独高度是个“玄学区”。你可以在配置面板里把区块宽度设成1200px但高度那一栏永远不在那里。很多做落地页的运营同学最后都是靠调整图片尺寸、添加空白占位块来间接控制高度这个方法在前端开发眼里就是凑合。这次更新主要就是解决三个高频问题第一视觉上多个区块需要保持等高等齐第二页面里需要加入整屏、半屏、固定高度这样的视觉区块第三内容长度不确定时希望区块至少保底高度不至于让页面看起来头重脚轻。1.1 页面高度一直“失控”的根源在哪里要理解这次更新的价值得先回顾一下之前的问题。区块在页面容器里的高度表现本质上取决于内容流区块内的文本多长图片多高按钮多占空间最终区块就被撑到多高。这在“文字为主”的长文页面里问题不大但一旦做起营销活动页、产品展示页、官网首页就非常痛苦。举个很常见的例子设计稿里一个产品介绍区块设计师画的是990px高。页面搭建人员在编辑器里把图片放进去、把文案复制进去却发现怎么调都到不了精确的990px多一行字太高删一行字又太矮。最后只能把图片高度拉长一点或者在外面缠一个空白占位块勉强凑出来。这类做法的隐患特别大。图片被强行拉伸之后在部分手机浏览器上会模糊空白占位块在响应式宽度下会出现高度比例失衡更别提运营后面自己去改文案一行字的变化就能让“辛辛苦苦对好的版式”整个错位。问题的根源不是运营不会排版而是区块本身没有一个可控的高度维度。1.2 一次真实的“事故”现场促使我把需求排上优先级说个具体案例。我之前帮一个团队处理过他们的活动页页面用了三个背景色相同的区块依次是品牌介绍、产品售卖、售后保障。三个区块连在一起视觉上要形成一整条连续的深色区域。结果产品售卖区的文案比预期多了几行那个区块的高度被撑高整条色带中断三块变成了三截中间的浅色背景露了出来特别难看。负责页面的同学当时的解决办法是在产品售卖区放一张巨大无比的占位图先把那个区域的高度固定住。页面打开是正常了但图片体积大加载明显变慢而且手机端显示时图片的固定高度又把其他区块挤得乱七八糟。这种情况下如果区块支持设置最小高度或者固定高度问题就简单得多。把品牌介绍设成固定高度产品售卖区设成最小高度内容长了自动向下延展色带依然连贯。这次更新从需求收集、方案设计到开发上线大概走了三周。我给自己定的原则是不做一个“能填高度数字”就完事的表面功能而是把三种常用模式、响应式表现、内容溢出的兜底策略全部一起考虑进去。2. 三种高度模式怎么选参数设计上我做了哪些权衡这次高度设置不是简单提供一个输入框而是拆成三种模式固定高度、最小高度、自适应高度。每多一种模式配置面板就多一分复杂度但少一种模式就有相当一部分场景用得不顺手。下面逐个聊我的设计思路和实际取舍。2.1 固定高度适用场景明确但要警惕溢出固定高度顾名思义就是用户设定一个具体的高度值区块在任何设备、任何内容量下都保持这个高度。它对应的 CSS 就是height: Npx。这个模式最适合那些内容完全确定的区块轮播图、封面头图、产品短描述展位、悬浮客服栏等等。举个例子你要做一个全宽的顶部 Banner设计稿规定高度是420px图片素材也正好按420px裁切好那么固定高度就是最省心的选择。不管以后后台内容怎么替换只要图片按规范提交区块永远严丝合缝。但固定高度有个天然的坑一旦内容超过设定高度要么破框而出、与下方元素重叠要么被裁切掉一部分。我在配置面板里专门做了“溢出提示”模式切换成固定高度之后渲染层会实时计算区块内部内容的实际高度一旦检测到内容高于固定值面板上会立刻出现警示文案并给出两个方向供选择——“增大高度”或“切换为最小高度”。而不是让用户发布页面之后才在浏览器里发现问题。在参数单位上固定高度的默认输入单位是 px但也支持 vh。因为很多运营会希望做“整屏首屏”这种效果直接输100vh就实现了如果不支持 vh强行让他们去算像素值那体验层面等于把这个功能废了一半。2.2 最小高度最推荐给内容不确定的场景最小高度对应的是min-height属性逻辑是区块实际高度不能低于设定值但如果内容更多区块会继续长高。它是这次更新里我个人最推荐的一个模式。请允许我说明为什么我如此推荐。因为页面里大多数区块的内容长度是动态的数据库里读出来的商品标题有时两行有时四行运营改了一个字段文案列表项多了一条。如果用固定高度那就是等着溢出如果用自适应视觉上可能撑不起设计稿想要的感觉。最小高度正好卡在中间——它保证区块在内容较少时依然拥有足够的存在感内容变多时又能灵活扩展。假设你正在搭一个产品陈列区每个产品卡片区块下方要对齐但卡片里的卖点文案长短不一。把每个卡片区块都设成最小高度360px哪个卡片内容不够就按360px显示哪个内容超过360px那个卡片就自动变高。这种模式既能保证底部对齐也不会因为某一个卡片内容过长就把其他卡片硬撑出空白。配置面板上最小高度模式还附带一个“子元素对其方式”的选项比如区块内的内容纵向靠上、居中还是靠下。这样在卡片高度有差异时可以让内部内容按统一的方式排列视觉上比单纯的“顶部对齐”更精致。2.3 自适应高度不设置但是一种“主动选择”自适应高度本质上就是不设置高度让区块回到“内容撑开”的老逻辑。既然这是以前就有的行为为什么还要作为一个模式放进配置面板因为一个成熟的功能面板必须同时给用户提供“可逆操作”。用户如果把区块设成了固定高度过两天想改回来他在面板里看到的应该是一个明确的选项“自适应”而不是空着高度输入框、不知所措。把这个模式单独拎出来用户在固定、最小、自适应三者之间反复切换时会非常顺畅每一次切换都能看到实时的预期效果。在实现层面自适应模式要做的反而不是“什么都不做”而是要把之前可能狗尾续貂的 inline style 清理干净。例如用户先设置了固定高度300px之后切换成自适应系统必须把区块上的height: 300px一并移除否则样式残留会导致页面依然呈现300px。这个清理逻辑需要在前端状态管理里做干净不能只改配置面板的显示状态。2.4 三种模式对比用一张表说清楚模式核心CSS效果适合场景风险点固定高度height: Npx永远保持设定高度轮播图、头图、确定内容的展位内容过多时溢出或裁切最小高度min-height: Npx不低于设定值内容多时自动长高卡片列表、活动区块、内容动态区几乎无最稳妥自适应高度height: auto完全由内容决定长文、详情段落、富文本区视觉上可能高度不够这张表是给所有使用区块的人看的。我的建议是拿不准的时候默认选最小高度不要选固定高度。3. 样式与数据层的实现细节这里最容易被忽略理论上给区块加一个高度设置只需要在元素上写个styleheight: 300px这谁都会。但放进一个页面编辑器的整体体系里周边要处理的细节比想象中多。这块可以细分成三个部分样式作用位置、优先级冲突、数据模型兼容。3.1 高度属性应该落在哪个元素上平台内部的区块结构大致是这样的div classblock-wrapper div classblock-body !-- 实际内容 -- /div /div这次高度设置作用于block-body而不是block-wrapper。原因有两点第一block-wrapper承担着定位、间距、对齐等布局职责如果在它上面强行设置高度会影响区块在画布中的拖拽和排列逻辑第二很多区块为了视觉效果会在block-wrapper上设置背景图或背景色如果背景容器的高度被锁死内容一变就会露出大片空白或者背景断层。所以我把高度设置在内部容器上。block-wrapper依然根据实际内容区域自适应而block-body则可以独立受控。这样区块的外部间距和内部视觉高度是两个维度的能力用户配置起来不容易互相干扰。3.2 样式优先级和 box-sizing 的坑设置高度时最容易翻车的地方是盒模型。区块默认样式里必须显式声明.block-body { box-sizing: border-box; }为什么要强调这个因为很多用户并不清楚当区块设置了固定高度300px同时又有上下 padding 各20px时内容区域实际可用的高度只剩260px。如果box-sizing是content-box那300px只是内容区高度加上padding后整个区块就会变成340px高用户看到的就是“我明明设置了300px怎么实际是340px”。这会直接打击用户对功能的信任感。因此所有高度设置生成的样式都会在标注了box-sizing: border-box的容器上追加确保height: 300px就是整体区块300px内部 padding 不影响总高度。另外需要处理的一个细节是固定高度模式下block-body内的子元素如果存在 margin 穿透也就是子元素的 margin-top 溢出到父容器外面会让实际显示高度看起来比设定值更“虚高”。针对这个我在区块内部加了一条规则.block-body { overflow: hidden; }但这在固定高度模式下可能造成内容被裁切所以这条规则只在最小高度和自适应模式下默认启用固定高度模式则由用户自己决定是否要开启内容裁切。3.3 数据模型怎么设计才能兼容历史页面页面编辑器的配置最终会落地成一份 JSON 结构。这次新增的高度设置在数据层的模型设计如下{ blockName: textBlock, heightSetting: { mode: minHeight, value: 320, unit: px } }mode取值为fixed、minHeight、auto三段。value是数字unit是单位当前支持px和vh。这里有个非常关键的兼容性问题所有历史区块配置里都没有heightSetting这个字段。因此后端解析的时候遇到heightSetting为空、缺失或mode为auto的情况一律按自适应高度处理绝不能抛错或报异常。这样老页面打开后所有区块的渲染表现和原来完全一致不会因为一次功能升级导致大面积页面错乱。渲染层拿到这个配置后生成内联样式。伪代码如下const modeMap { fixed: height, minHeight: min-height, auto: height }; function applyHeightSetting(setting) { if (!setting || setting.mode auto) return {}; return { [modeMap[setting.mode]]: ${setting.value}${setting.unit} }; }这块逻辑看起来简单但要注意一个点当用户从固定高度切换到自适应高度时生成的样式对象里不能残留height字段。所以函数开头要先判断mode auto时直接返回空对象而不是返回{ height: auto }。返回值虽然视觉上都是没有固定高度但空对象可以让面板上的样式编辑器判定为“未设置过”避免在后续其他编辑操作中留下冗余的内联属性。3.4 溢出检测是怎么做的固定高度模式下我需要实时告诉用户内容是否溢出。这块是通过ResizeObserver监听block-body内部内容的高度变化实现的const bodyEl block.querySelector(.block-body); const observer new ResizeObserver(() { const contentHeight bodyEl.scrollHeight; const setHeight bodyEl.offsetHeight; const isOverflow contentHeight setHeight; if (isOverflow) { panel.showWarning(内容实际高度 ${contentHeight}px 超过设定值 ${setHeight}px); } else { panel.hideWarning(); } }); observer.observe(bodyEl);性能上这是一个轻量级的监听区块数量和观察器数量都限制在页面内可见区块范围内。用户编辑一个区块时只对当前正在编辑的区块做观察其他区块不激活观察器避免大页面卡顿。4. 实测半小时我抓到四个“高度杀手”边缘情况功能开发完进入实测阶段后边缘情况一个接一个冒出来。这一节记录四个我印象最深的坑每一个都值得做类似功能的团队提前规避。4.1 嵌套区块的高度继承问题页面里经常出现区块套区块的结构外层一个容器区块里面嵌套两个左右排列的子区块。子区块设置固定高度时理论上没问题但外层容器区块如果同时开启了高度设置inner 区块的百分比高度就会失效。我举一个具体例子外层容器设成了固定高度500px内层左子区块设置高度为100%。这个 100% 参照的是内层容器的 content 高度而内层容器在固定高度的父级下面本身没有明确高度最终渲染结果可能不是用户预期。这个问题在实测中让我很困扰因为表现不一致。最后我的处理方式是内层区块的高度百分比在区块多级嵌套时面板上默认禁用%单位只保留px和vh。等嵌套结构变了或者外层高度也明确设置了%单位再根据需要开放。页面编辑器面向的用户不全是专业开发者功能越灵活翻车的姿势就越多样适当收窄单位选项也是一种保护。4.2 响应式断点处的高度不自动缩放区块在桌面端和移动端通常使用不同的布局比例。这次高度设置上线后如果用户给区块设了固定高度600px在桌面端看起来没问题但手机端打开区块依然还是600px高在窄屏上就会显得特别“巨”。这个问题的本质是宽度变了高度没变比例自然失衡。我一开始想过做“按比例缩放”的自动逻辑即高度值随着视口宽度等比伸缩但测试后发现不可行——区块内部的内容是真实文本和图片不是纯图形高度等比缩放会导致文字错位和图片变形。最终我的方案是固定高度支持配置多个断点值。桌面端、平板、手机各可以单独设一个高度数值默认从桌面端继承。移动端的常用策略是如果区块内容较多就把高度模式改成最小高度让内容自然撑起如果确实需要固定再单独设置一个适合移动端的较小值。这个逻辑在配置面板上用三个标签页来呈现清晰度比一个单一的高度输入框要好很多。4.3 背景图与固定高度之间的“断层”很多区块会设置背景图。当区块设置了固定高度背景图的background-size必须同步调整。默认背景图尺寸是cover也就是覆盖整个区块但这会导致一个问题图片被裁切的部分在不同高度下显示的内容不同。用户在设计稿里看到的背景图重点区域是左侧固定高度改变后背景图重新裁切重点区域可能跑到画面外。这个不算 bug但属于很影响体验的“非预期行为”。我在面板上增加了一行说明当高度变化后背景图显示区域可能发生偏移建议开启“背景图视口固定”选项也就是让背景图基于区块顶部对齐而不是垂直居中。这样用户控制起来更有确定性。4.4 高度设置对页面自动锚点定位的影响页面里经常有“点击按钮跳转到某个区块”的锚点交互。以前区块高度是内容撑开的锚点定位基本准确。加了自定义高度之后特别是区块内部内容较少、区块本身靠最小高度撑得很高时锚点会跳到区块顶部视觉上会感觉跳转位置偏了因为区块下半部分是大量的空白。这个问题的修复方式比较直接锚点跳转时不再以区块顶部为基准点而是以区块内实际内容的第一个元素为基准点。技术上是获取区块内部第一个子元素的位置来计算滚动偏移。这个需求一开始并没有想到是在用户内测群里有人反馈“点了跳转位置不对”我才意识到高度设置还会跟锚点机制产生耦合。这类边界情况就是做功能时最典型的“想不到”。5. 这次更新沉淀下来的一些取舍与个人体会功能发布之后的灰度观察期我一直在看后台埋点数据。目前三种模式的使用占比中最小高度最高自适应第二固定高度第三。这验证了之前的判断大家最需要的是“保底高度”而不是真正的锁死。运营搭页面时永远要防着内容变化固定高度对他们来说反而像一颗定时炸弹。在单位输入上px 依然是绝对主力但 vh 的使用占比在首屏区块场景里非常突出。很多用户事实上不知道 vh 和 px 的换算他们只需要“这个区块占一屏”至于一屏是多少像素完全不想关心。以后如果要继续优化我可能会把”满屏高度“作为固定高度的快捷按钮单独提出来连输入 vh 这步都省掉。另外一点深刻体会是给编辑器做功能交付的不只是功能本身还需要把“功能会在什么场景下翻车”一并交付。这次高度设置涉及的溢出检测、响应式断点、背景图裁切、锚点定位任何一个环节没有提醒或兜底发布后都会演变成工单。实际开发里有一个用户场景我之前完全没有预期到——他用固定高度做“楼层导航”区块把区块高度精确设成了最终验收时设计稿的高度然后用这个区块去承载后续几乎所有自定义内容这其实已经超出了当时设计的初衷。但系统没拦着他反而这种用法让他觉得工具更通人情了。如果现在让我评价这次区块高度设置功能我会说基础能力本身不难难的是让它在一个复杂编辑器里“不出戏”。每次给平台加上一个新属性背后的连锁反应都像推倒一列多米诺骨牌你能做的就是把每一张牌的位置都提前看清再把手放开。