流程控制不参与物理占比计算，仅调度测算时机；真实空间占比必须由前端通过getboundingclientrect()、devicepixelratio等浏览器api实时测量并上报后端校验存储。
流程控制本身不参与物理占比计算，它只决定“何时算、按什么条件算、算完怎么走”。真正的空间物理占比必须由前端基于 DOM 实际渲染结果来测量，后端无法获取设备像素比、视口尺寸、缩放状态等关键信息。
前端才是占比计算的唯一执行层
组件在屏幕上的真实宽高、位置、缩放影响后的实际尺寸，只能通过浏览器 API 实时获取：
- getBoundingClientRect()：获取元素相对于视口的像素级位置和尺寸
- window.devicePixelRatio：校正高清屏下的物理像素偏差
- getComputedStyle(element)：读取 transform、scale 等影响布局的最终样式
- ResizeObserver：监听容器或窗口变化，触发重新测算
例如，一个弹窗拖拽结束时，应立即调用：
const rect = el.getBoundingClientRect();
const ratio = (rect.width / window.innerWidth) * 100;
这个 ratio 才是真实的宽度占比（如 32.5%）。
流程控制的作用是调度与决策
所谓“用流程控制动态计算”，实质是把占比获取嵌入到合理的交互生命周期中，而非让流程去替代计算本身：
- 拖拽开始前：记录初始缩放比、视口尺寸，形成闭包上下文
- 拖拽过程中：不实时计算占比（性能差），仅记录位移偏移量
- 拖拽结束（mouseup/touchend）：触发一次精准测算，结合闭包中的缩放比反算原始设计稿坐标
- 尺寸变更时（如窗口 resize 或容器折叠）：通过 ResizeObserver 触发重算并上报
后端只接收、存储、校验，不计算
前端将测算结果（如 {"id": "chart-1", "x": 42.3, "y": 28.7, "width": 25.0, "height": 12.5}）以轻量 JSON 形式 POST 至后端接口（如 /api/v1/layout/save）。后端职责明确：
- 校验 x + width ≤ 100，防止超出画布逻辑边界
- 按组件 ID 关联用户、看板、版本等元数据存入数据库
- 提供快照还原能力：下次加载时，直接按占比值还原布局（非像素值）
- 不解析注解、不调用反射、不启动线程池、不执行 arraycopy
“布局注解”需前置转换为可运行逻辑
如果使用了类似 @WidthRatio(0.3) 的自定义注解，它只在构建期或初始化阶段生效：
- 编译时通过 APT 提取注解值，生成配置 JSON 或注入 JS 变量
- 运行时前端读取该比例，在父容器尺寸就绪后（如
el.parentElement.offsetWidth）计算像素值并设置el.style.width - 注解本身不是实时测量依据——它只是初始配置，真实占比仍取决于最终渲染结果
