先说个背景，我自己常年跟各种可视化大屏、Dashboard、低代码搭建平台打交道。前阵子在一个开源仪表板系统里提了一个feature request：自定义容器（custom containers）要支持可调尺寸，并且在没有内容的时候要能显示占位图（placeholder image）。这个需求看起来很小，但真的落地的时候牵扯出一堆东西——布局引擎怎么选、占位图状态怎么触发、iframe加载失败怎么办、尺寸要不要持久化。这篇文章就把这个需求从头到尾拆开聊一遍，既说思路，也讲实现，还把我踩过的坑一并列出来。

我写的东西主要是给三类人看的：正在用可视化平台但觉得容器组件不够灵活的人，自己在写低代码/大屏项目需要实现类似功能的开发者，还有想给开源项目提PR但不知道从何下手的朋友。如果你只是临时遇到了“容器不能调大小、空白时很难看”的问题，也能在后面的临时方案里找到直接能用的代码。

1. 这个需求到底在说什么：自定义容器带来的真实痛点

1.1 什么是“自定义容器”，它一般出现在哪里

自定义容器这个东西，不同平台叫法不一样，有的叫HTML容器、有的叫iframe容器、有的叫自定义区块，但本质都是同一个东西：一个可以在里面嵌入任意网页、图片、视频、HTML片段、甚至第三方系统页面的盒子。常见场景包括：

• 智能家居控制面板里嵌入摄像头直播流、天气预报页面
• 数据中台大屏里嵌入报表系统、GIS地图、外部监控页面
• 低代码建站工具里嵌入自定义HTML/CSS/JS代码块
• 企业门户里嵌入OA、CRM等系统的内嵌页面

容器本身不关心你塞进去的是什么，它只负责提供一个“框”，并且保证这个框在画布上按预期显示。但问题恰恰出在这个“框”上——大多数平台默认只给固定尺寸，或者只给几个预设比例，用户想拉大一点、收窄一点，根本做不到。容器内容为空或者加载失败的时候，平台也是一片空白，没有任何提示和兜底。

1.2 没有“可调尺寸”和“占位图”时的尴尬体验

我实际遇到的情况是这样的：在某平台上搭一个大屏监控页，里面要放一个视频监控的iframe。默认容器宽高是固定的，我需要的比例是4:3，平台给的是16:9；拖也拖不了，只能去改全局配置，结果改了全局，其他页面全部跟着变形。后来我换了思路，不用iframe，改用图片轮播，结果某一路摄像头断流，图片源加载不出来，整个容器就变成一个黑底白字的空白框。演示给客户看的时候，客户指着那个空框问：“这是预算没批下来所以没装摄像头吗？”——你说尴尬不尴尬。

占位图这个东西，很多人觉得只是一个锦上添花的小功能，但实际上它的价值在于“兜底”。一个容器加载外部内容，至少有三种情况会失败：网络慢、内容源宕机、权限校验失败。如果没有占位图，用户看到的是一块空白；如果有占位图，用户至少知道“这里本来应该显示什么”。这个信息对观感、对排障、对演示，都非常重要。

1.3 使用者和开发者对这个需求的视角差异

有意思的是，同一个feature request，使用者和开发者的理解完全不一样。

使用者的诉求很简单：我要能拖大小，我要在空白处看到好看的图。

开发者第一反应则是：可调尺寸是用绝对像素还是百分比？要不要吸附网格？用户把容器调得很大，旁边容器怎么办？占位图是加载前显示还是加载失败后显示？占位图是静态图片还是要支持自定义上传？这个功能的优先级在整个迭代里排第几？

所以一个feature request虽然一句话就能写出来，但真正要落地，背后是一连串方案选型和工作量评估。这也是为什么很多开源项目的维护者收到类似请求后，第一反应是让你“先描述清楚使用场景”，而不是直接答应你。理解了这一点，你再看后面几节，思路就会清晰很多。

2. 方案选型：可调尺寸的四种实现思路

2.1 绝对像素拖拽调整：最直观但最不省心

第一种方案就是给容器加一个拖拽手柄，用户按住右下角拖，宽高直接按像素变化。

优点非常明显：直观、所见即所得、实现简单。前端做这个只需要监听mousedown/mousemove/mouseup，算一下偏移量，更新容器的width和height就够了。

缺点也致命：不同分辨率的屏幕上效果完全不一样。用户在自己1920宽的笔记本上把容器拖到1600px宽，看起来刚好；换到1366宽的笔记本上，容器直接超出画布，横向滚动条就出来了。更麻烦的是，很多可视化平台是自带响应式布局的，你用绝对像素改了一个容器的尺寸，整个页面的栅格系统就被打破了。

所以绝对像素方案只适合固定分辨率的大屏场景——比如投放的广告大屏、机房监控屏——以及快速原型验证。不建议作为通用方案。

2.2 百分比自适应：优先保证不死板

第二种方案是让容器尺寸用百分比表示，拖拽的时候实时计算容器相对于父容器的宽高比例。

优点：不会破坏响应式布局，父容器缩小时，子容器跟着缩小，不会溢出。

缺点：拖拽体验不如像素直观。用户拖动5个像素，反映到百分比上可能只有0.1%，感觉“拖了没反应”。而且百分比方案对父容器高度不确定的场景比较麻烦，父容器高度是auto时，子容器高度百分比会被忽略。

我个人的结论是：百分比适合作为容器尺寸的“保存格式”，作为存储和计算依据，而不是直接作为拖拽操作的单位。

2.3 栅格/网格吸附：大屏和Dashboard的事实标准

第三种方案是栅格布局。画布被划分成若干行若干列，容器只能放在网格的交叉点上，宽高也以“跨多少行、跨多少列”来体现。这个方案在Grafana、Home Assistant的Dashboard、各种BI系统里都是事实标准。

实现上主要靠CSS Grid或绝对定位加坐标换算。用户拖拽时，鼠标移到的位置会被换算成网格坐标，然后自动吸附到最近的网格线。这样做的好处是：不管怎么拖，布局始终整齐，不会出现容器之间“互相压住一条边”的尴尬缝隙。

这种方案的缺点是需要一套坐标换算逻辑，开发成本比前两种高。而且网格粒度需要配置，网格太大不够灵活，网格太小又失去了自动对齐的意义。我一般建议网格粒度默认12列，行高按75px或80px，这样既能保证灵活度，又能跟大多数设计器的默认配置对齐。

2.4 混合方案：栅格为主、像素微调兜底

我最终给那个feature request建议的是混合方案：栅格决定大体位置和尺寸，容器拖拽结束后自动贴齐网格；同时提供一个“自由调整”模式，开启后用户可以在栅格的基础上继续用像素级微调，调整的最小步长是1px。这样兼顾了布局整齐和用户自由度，也避免了单个方案各自的短板。

如果你自己写前端，这个混合方案并不复杂。核心思路是：给容器同时维护两套尺寸数据，一套是栅格坐标（gridX, gridY, gridW, gridH），另一套是像素偏移量（offsetX, offsetY）。保存时优先保存栅格坐标，微调偏移量作为附加字段存储。渲染时先用栅格坐标定位，再把偏移量加上去。用公式表示就是：

实际宽 = gridW × 单元列宽 + offsetX
实际高 = gridH × 单元行高 + offsetY

这是我多次实践后比较推荐的做法。如果你是在现有平台上提需求，那么在方案建议部分也尽量往这个方向写，维护者会认为你确实想过需求背后的工程问题。

下面用一个表格把这四种方案快速对比一下：

方案	实现成本	响应式适配	布局整齐度	适用场景
绝对像素拖拽	低	差	一般	固定分辨率大屏、快速原型
百分比自适应	中	好	一般	流式布局、响应式页面
栅格吸附	高	较好	好	Dashboard、BI、低代码平台
栅格+像素微调	较高	较好	好	复杂自定义需求、企业级平台

3. 占位图的实现细节：从触发条件到图片格式

3.1 占位图应该在哪些时刻出现

很多人以为占位图就是“没内容时显示一张图”，实现的时候就是判断一下容器内容是否为空，空就显示、非空就隐藏。实际上占位图的触发场景至少应该拆成四种：

加载中 。外部iframe或图片还在请求，此时显示一个加载中的占位样式。这类占位图一般是轻量的骨架屏，或者一个居中的loading图标，不推荐用大图，因为过一会儿就会被真实内容覆盖，太复杂的加载占位反而会让页面看起来闪烁。

加载失败 。外部内容源返回404、500，或者iframe被目标站点通过X-Frame-Options禁止嵌入，此时应该显示错误提示型占位图。这类占位图要明确告知用户“内容加载失败”，最好同时给出一个重试按钮。

内容为空 。加载成功，但内容本身是空的（比如某些报表系统查询结果为空）。此时显示的是空状态占位图，提示文案一般偏“暂无数据”风格。

功能未授权 。这一点比较容易被忽略。一些高级容器功能（比如自定义脚本注入、外部域名白名单）在商业平台里是受license控制的，如果用户当前授权不包含这个feature，调用相关API时控制台会报“license request failed for feature”之类的错误。这种场景下，占位图应该提示用户“当前版本不支持该功能，请联系管理员开通”，而不是让用户看到一片空白然后一头雾水。

触发条件梳理清楚之后，占位图组件本身应该是一个状态机，至少包含四个状态：

idle -> loading -> success 或 error
                  └--> empty

状态流转逻辑如下：容器挂载后进入loading状态，同时开始加载真实内容；加载成功且内容非空，切换为success，隐藏占位图；内容为空，切换为empty；任何环节出错，切换为error，显示重试按钮。

3.2 占位图的图片格式与加载方式怎么选

占位图本身的实现方式有几种，我分别说下优缺点。

第一种是纯CSS绘制。用背景色、边框、文字、CSS动画来组成占位图。优点是不需要额外的图片资源，加载速度最快；缺点是表现力有限，复杂的插画风格做不出来，只能用简单的线条和文字。

第二种是SVG内嵌。SVG是矢量格式，任意缩放不变形，文件体积小，可以做比较丰富的图形内容（比如一个居中的图标加一段文字说明）。推荐的做法是把SVG直接内联在页面代码里，或者存成独立的.svg文件。

第三种是PNG/JPG位图。适合需要精美插画的场景，但缺点也很明显：位图在2x、3x的Retina屏上会发虚，需要准备多倍图；文件体积也更大，如果占位图比较多，会影响页面加载速度。

从我自己的实践来看，加载中状态用纯CSS实现的骨架屏，空状态和错误状态用内嵌SVG，整体体验是最均衡的。既保证了加载速度，又能有足够的信息表达能力。

还有一个细节：占位图资源要不要内嵌base64。我的建议是，如果占位图很小且数量不多，可以直接base64内嵌，省掉一次网络请求；如果是一个需要统一管理、支持用户自定义上传的占位图库，应该用静态资源URL的方式，方便更新和缓存。

3.3 占位图与真实内容的联动机制

占位图不是静态贴上去的，它需要跟真实内容的状态联动。下面是一段框架无关的思路描述，用JavaScript伪代码表示：

const container = document.querySelector('.custom-container');
const placeholder = container.querySelector('.container-placeholder');

function setContainerState(state) {
  placeholder.dataset.state = state;
  placeholder.classList.remove('is-loading', 'is-error', 'is-empty', 'is-hidden');
  
  switch (state) {
    case 'loading':
      placeholder.classList.add('is-loading');
      break;
    case 'error':
      placeholder.classList.add('is-error');
      break;
    case 'empty':
      placeholder.classList.add('is-empty');
      break;
    case 'success':
      placeholder.classList.add('is-hidden');
      break;
  }
}

逻辑本身非常简单。真正的难点在于如何“判断加载成功/失败/为空”，这取决于你嵌入的内容类型。

如果是iframe嵌入，你需要监听iframe的load事件。但这里有一个坑：iframe的load事件有兼容性问题， iframe.onload 在跨域情况下不同浏览器行为不一致。相对可靠的做法是设置一个超时时间（比如10秒），超时后如果还没有触发load事件，就认为加载失败。另外，如果目标是同源页面，你还可以通过window.postMessage和后端接口做更精确的状态上报。

如果是图片嵌入，监听img的load和error事件就行。这里要专门注意一个坑：如果你在图片加载完成前就给它设置了src，然后又修改了src，浏览器可能只触发一次error事件，之后就再也不会触发load了。这个问题的排查方式，我放在第五节“常见问题实录”里细说。

如果是fetch拉取HTML片段再插入容器，那么fetch返回后的状态判断就完全由你控制，相对最简单。代码如下：

async function loadContainerContent(url) {
  setContainerState('loading');
  try {
    const res = await fetch(url);
    if (!res.ok) throw new Error(`HTTP ${res.status}`);
    const html = await res.text();
    if (html.trim() === '') {
      setContainerState('empty');
      return;
    }
    container.innerHTML = html;
    setContainerState('success');
  } catch (err) {
    setContainerState('error');
  }
}

这个写法已经可以直接用在小型项目里。如果你需要在大型项目里用，建议再加一层AbortController来做超时取消，避免长时间挂起的请求把状态卡在loading。

4. 实操案例：在现有平台上先自实现一套“可调尺寸+占位图”

4.1 用CSS Resize属性快速实现“可拖拽调整”

如果你用的平台暂时不支持这个feature，但支持自定义HTML/CSS，那你可以先自己临时顶上。最便捷的方式是CSS的resize属性——这是一个被很多人忽略的原生能力。

.custom-container {
  resize: both;
  overflow: auto;
  min-width: 200px;
  min-height: 150px;
  max-width: 100%;
  border: 1px dashed #ccc;
  background: #fafafa;
}

加上这段代码，浏览器会在容器右下角自动渲染一个拖拽手柄，用户按住就可以调整宽高。 overflow: auto 是必须的，没有这个属性resize不生效。 resize: both 表示水平和垂直方向都可以拖，也可以改成 horizontal 或 vertical 限制方向。

这个方案的优点是零JavaScript，几行CSS就实现了。缺点也很明显：尺寸调整结果不会保存，刷新后就复位了；没有网格吸附；对移动端触摸事件支持较差。它适合做快速原型验证，或者作为等待官方功能上线的过渡方案。

4.2 从“临时方案”升级成“可保存方案”

CSS resize不能保存尺寸，这是最大的短板。解决办法是用JavaScript读取容器的尺寸，存到localStorage，下次加载页面时再恢复。

完整的实现思路是这样的：

监听容器大小变化。用MutationObserver可以监听style属性的变化，即使用户是通过CSS resize手柄拖动，style属性也会被实时更新。代码如下：

const container = document.querySelector('.custom-container');
const STORAGE_KEY = 'custom-container-size';

function saveSize() {
  const rect = container.getBoundingClientRect();
  const data = { w: Math.round(rect.width), h: Math.round(rect.height) };
  localStorage.setItem(STORAGE_KEY, JSON.stringify(data));
}

function restoreSize() {
  const raw = localStorage.getItem(STORAGE_KEY);
  if (!raw) return;
  try {
    const data = JSON.parse(raw);
    if (typeof data.w === 'number' && typeof data.h === 'number') {
      container.style.width = data.w + 'px';
      container.style.height = data.h + 'px';
    }
  } catch (e) {
    // 解析失败不做处理，让容器使用默认尺寸
  }
}

const debounceSave = debounce(saveSize, 300);
new MutationObserver(debounceSave).observe(container, {
  attributes: true,
  attributeFilter: ['style']
});

restoreSize();

这里用防抖去处理保存频率，不然每次拖拽过程中style属性都在变化，会频繁写入localStorage，造成性能消耗。防抖时间我常用300ms，既能及时保存，又不会太频繁。

需要注意的一个小坑是：容器默认尺寸和localStorage里保存的尺寸可能差距很大，比如用户在1920屏上把容器拖到1800px宽，然后在1366的笔记本上打开页面，恢复后的容器就会超出可视区域。所以恢复尺寸前，最好先做一次边界校验：如果保存的宽度大于容器父元素宽度的95%，就按父元素宽度的95%来恢复。这也呼应了前面栅格方案里提到的边界思想。

4.3 占位图兜底：写一个通用EmptyState组件

占位图我通常和状态逻辑写成一个独立组件，方便复用。这里给出一个直接用HTML/CSS/JavaScript实现的最小示例：

<div class="custom-container">
  <div class="container-placeholder" data-state="loading">
    <svg class="placeholder-spinner" viewBox="0 0 18 18" width="18" height="18">
      <circle cx="9" cy="9" r="7" fill="none" stroke="#c0c0c0" stroke-width="2"/>
      <path d="M9 2a7 7 0 0 1 7 7" fill="none" stroke="#666" stroke-width="2"/>
    </svg>
    <span>内容加载中...</span>
  </div>
  <div class="container-content">
    <!-- 真实内容渲染在这里 -->
  </div>
</div>

.container-placeholder {
  position: absolute;
  inset: 0;
  display: flex;
  align-items: center;
  justify-content: center;
  gap: 8px;
  background: #fafafa;
  color: #999;
  font-size: 14px;
  z-index: 10;
}

.container-placeholder[data-state="loading"] svg {
  animation: spin 1s linear infinite;
}

.container-placeholder[data-state="error"] {
  background: #fff7f7;
  color: #d9534f;
}

.container-placeholder[data-state="empty"] {
  background: #fafafa;
}

.container-placeholder[data-state="hidden"],
.container-placeholder[data-state="success"] {
  display: none;
}

@keyframes spin {
  from { transform: rotate(0deg); }
  to { transform: rotate(360deg); }
}

这里用的是纯CSS+内联SVG的方式。相比贴一张PNG占位图，这种做法的好处是：状态切换可以只改data-state属性，视觉样式全部由CSS控制，逻辑和样式完全分离。后面你想把“加载中”从转圈换成进度条，只需要改CSS，不用动JS。

4.4 关于“license request failed for feature”这个报错

这个报错我遇到过几次，而且每次都是在我试图使用一些“高级容器功能”的时候弹出来。比如有个平台上，自定义容器的“去除品牌水印”功能、以及“任意尺寸设置”功能，是分在高级license里的。我提的feature request里包含了“可调尺寸”，但平台的免费版给出的响应不是“功能不支持”，而是调用内部接口时直接抛一个license请求失败的错误。

排查时我从三个方向入手：

第一，确认当前使用的账号/license套餐包含哪些功能权限，这条信息通常在平台的订阅管理或控制台设置里能看到。

第二，检查调用链里有没有被降级处理。有些平台会做能力探测，授权不足时自动降级到基础能力，有些平台则直接抛错。有没有办法绕开？我试过直接用CSS覆盖尺寸，虽然页面视觉上能改变容器大小，但一旦触发平台的保存/同步逻辑，修改会被覆盖回去。所以“绕过授权”这条路基本走不通，老老实实升级套餐或者等官方放开权限才是正道。

第三，如果你是自己搭的开源平台，遇到“license request failed for feature”这类报错，多半是配置的License Key和当前应用版本不匹配。检查一下License Key是否过期，或者和供应商确认授权范围是否包含了当前版本的feature标签，这个比较常见。

这一段也算是对这个feature request的一个补充：功能需求本身是后端和前端的问题，但如果你的项目跑在带有商业授权的框架之上，授权范围也可能会变成卡点之一。

5. 常见问题与排查技巧实录

我在实现“可调尺寸+占位图”的过程中踩了一堆坑，这里挑几个典型的记录下来，方便大家直接对照排查。

问题现象	可能原因	排查思路与解决办法
拖拽时容器超出父元素边界	缺少边界限制逻辑	在拖拽事件中计算容器不应小于min-width/min-height，不应大于父元素宽高的百分比上限；或者给容器设置max-width: 100%
占位图怎么都不显示	容器内容覆盖了占位图	检查占位图z-index是否足够高；检查容器内容区是否设置了不透明背景色；检查占位图是否被display:none条件误隐藏
图片加载错误后占位图不恢复	修改src时未重置img状态	在设置新src之前先移除旧图片，或调用img.removeAttribute('src')后重新赋值，避免浏览器缓存旧错误状态
刷新后容器尺寸恢复默认	localStorage存储失败或读取时机不对	检查localStorage是否被浏览器禁用；检查组件是否在DOMContentLoaded之前执行了读取逻辑
嵌入iframe后容器高度不准确	iframe内部内容高度变化	同源场景下可以用postMessage传递内容高度，跨域场景下建议改用自适应组件或给容器设置固定的高宽比例
大屏适配时容器变形	只设置了宽高，未设置内容object-fit	如果容器内容是图片或视频，给内层元素加object-fit: cover或contain；如果是iframe，考虑固定比例并居中显示
拖拽过程中页面卡顿	拖拽事件频繁触发重排	用requestAnimationFrame包一层再更新样式，或者拖拽时用transform代替width/height，拖拽结束后再归一化到实际宽高
控制台报license request failed for feature	当前授权不包含对应feature	核对授权范围；如果是自己的平台，检查license key是否与当前版本匹配；不要试图绕过授权，大概率会在数据同步阶段被覆盖

上面有几个坑值得展开说明一下。

关于图片error事件不触发的问题。 我之前遇到的情况是：轮播图切换时，第二张图加载失败，但我把onerror挂在了img元素上，它就是不弹。后来发现原因是第一张图加载失败后，onerror已经被触发过一次，第二次修改src时，浏览器内存里还残留着上一次的error状态，不会再触发新的error事件。解决办法是每次切换前移除旧的img元素，或者用new Image()预加载，成功后再替换到DOM里。

关于防抖和节流的选择。 保存容器尺寸时我用的是防抖，因为我要的是“用户停止拖拽后的最终结果”，而不是“拖拽过程中的每一个中间值”。但如果某个需求是“拖拽过程中实时同步给其他人预览”，那就要用节流而不是防抖。两者别搞混，否则要么保存太频繁，要么交互迟钝。

关于MutationObserver监听style属性。 这个方案的兼容性很好，主流浏览器都支持。但要注意：如果你自己在代码里修改容器尺寸，也会触发MutationObserver回调，如果修改尺寸的地方又调用了saveSize，就形成了循环保存。所以saveSize函数里最好加一个标志位：如果是代码内部修改触发的observer，就跳过保存。

6. 给开源项目提这个feature request，怎么写才容易被采纳

6.1 一份高质量feature request应该包含什么

如果你也想在某个开源项目里提这个需求，建议不要只写一句“希望支持可调尺寸和占位图”，而是按照下面的结构来写：

• 背景 ：当前自定义容器的尺寸是固定的/只有预设比例，用户需要更灵活地控制布局；容器内容加载失败时显示空白，影响观感和排障效率。
• 使用场景 ：给出至少两个真实场景。比如“嵌入外部监控页面时，不同来源的内容比例不同，固定比例会导致裁切”；“内容源宕机时，画布上出现空白区块，演示时无法解释”。
• 期望行为 ：明确描述期望的交互方式。支持拖拽调整宽高，支持最小/最大尺寸限制，支持栅格吸附；容器在加载中、加载失败、内容为空时分别显示不同的占位图。
• 可选方案建议 ：结合我前面说的栅格+像素微调混合方案，或者提供你自己的实现思路。维护者看到你已经有技术预研，采纳概率会大很多。
• 影响范围与风险 ：这个功能会影响哪些模块，有没有迁移风险。比如改动布局引擎会不会影响已有仪表板。
• 验收标准 ：列出关键的验收测试用例，比如“拖拽后刷新页面尺寸保持”、“加载失败后显示错误占位图并能重试”。

6.2 一个可以直接用的feature request模板示例

下面是我当时提交时的内容结构，你可以直接改改复用：

标题：Custom containers: support adjustable size and placeholder image

背景：
当前自定义容器仅支持固定尺寸和预设比例，无法满足不同外部内容源的展示需求。
且当容器内部内容加载失败或为空时，界面显示为空白区块，用户无法判断区块用途。

使用场景：
1. 在监控大屏中嵌入第三方摄像头直播页面，不同页面比例不同，固定比例会导致画面裁切。
2. 播放器的内容源由于鉴权/网络原因加载失败，界面出现空白，影响演示和排障。

期望行为：
1. 自定义容器支持拖拽调整宽高，支持最小/最大尺寸限制，可选网格吸附。
2. 容器内容状态区分为加载中/加载失败/内容为空，分别显示对应的占位提示。
3. 尺寸设置可持久化保存，项目重新加载后还原。

参考方案：
- 尺寸存储建议采用栅格坐标加像素偏移量的混合方案...
- 占位图建议按状态机方式实现，加载中使用骨架屏，错误状态显示重试按钮...

影响范围：
- 布局引擎（新增尺寸计算逻辑）
- 容器渲染模块（新增占位图状态控制）
- 配置存储（新增尺寸字段）

验收标准：
- 拖拽调整容器宽高，刷新页面后尺寸保持。
- 模拟加载失败，容器显示错误占位图，点击重试后恢复正常。
- 在移动端浏览器中，容器不会超出可视区域。

6.3 如果等不及官方支持：先fork再自实现，然后回提PR

开源项目的feature request从提出到合入，往往要经历需求讨论、方案评审、代码实现、评审修改、合并发布几个阶段。如果项目很活跃，周期大概一两个月；如果项目维护者少，半年没动静也很正常。

所以如果这个功能对你很重要，我的建议是直接fork一版自己实现。你在fork分支里做出来的方案，如果质量不错，可以作为reference implementation回提给原项目，维护者大概率会参考你的思路。我当时就是这么干的：先用CSS resize配合localStorage做了一版临时实现，同时给原项目提了详细的feature request，后来官方在下一个大版本里做了相似的功能，虽然不完全是我当初的方案，但整体思路基本一致。

如果你要自己实现，建议按这个顺序来做：

1. 先把尺寸调整的交互做出来（拖拽手柄或CSS resize都行）。
2. 再把尺寸持久化加上（localStorage或者直接写入配置）。
3. 然后加占位图状态机（loading/error/empty）。
4. 最后做兼容性收尾（移动端触摸、边界限制、防抖节流）。

这样一个阶段一个阶段推进，每一步都可以独立验证，不容易翻车。

---

这个功能看起来不起眼，但牵扯出来的布局引擎、状态机、存储策略、授权边界，每一项在真实项目里都是硬骨头。我自己在实现过程中最深的体会是：占位图一定要当成“一等公民”来设计，而不是一个临时贴上去的图片。因为占位图的触发时机，其实决定了你在容器的生命周期里到底监控了多少关键节点。如果你只处理了“内容为空”这一种情况，那加载失败、加载超时、权限不足这些场景迟早会找上门来。

最后再分享一个小技巧：如果你在调试占位图显示状态，建议在浏览器开发者工具里直接手动改占位图元素的data-state属性。比如在Elements面板里把 data-state 从 success 改成 error ，看样式是否能正确切换。这个调试方法比反复改逻辑代码要快得多，能帮你快速区分“是状态机逻辑错了”还是“是CSS样式没写对”。