Fixed-header tables force one getBoundingClientRect per column on every mount (ResizeObserver-driven MeasureCell)

从 Body/MeasureCell.js 和 useResizeObserver.js:20 开始，然后复现一个使用 scroll.y 的固定表头表格，并按描述对其 cold mount 进行性能分析。完成标准是确定按列读取是否出于有意，并在不改变观察到的表格行为的情况下，找出或实现成本更低的测量路径。

Environment

• @rc-component/table: 1.10.4 (via antd 6.5.3)
• @rc-component/resize-observer: 1.1.2
• Chrome, production build, 4x CPU throttle (DevTools)

What we observed

Any table mounted with a fixed/scrollable header (scroll.y set, i.e. fixHeader true) renders a hidden "measure row" with one MeasureCell per column. Each MeasureCell wraps its cell in a ResizeObserver (Body/MeasureCell.js), and on the initial observe, onInternalResize (useResizeObserver.js:20) calls target.getBoundingClientRect() once per cell.

On a ~40-column table, we measured 86 getBoundingClientRect calls totaling ~547ms of forced-layout self-time on a single cold mount, instrumented by wrapping HTMLElement.prototype.getBoundingClientRect/offsetWidth and measuring with performance.now(). This is currently the dominant forced-layout cost on table mount in our app (a general-purpose ERP list view), well above what column count alone would suggest — the reads don't appear to be batched into a single reflow.

Question / ask

Is per-column ResizeObserver-driven measurement (as opposed to reading all column offsetWidths in one synchronous batch, which the browser can usually satisfy with a single layout pass) intentional, or is there a lower-cost path we're missing (e.g. skipping remeasurement when explicit pixel widths are already provided for every column)? Happy to share a minimal repro or profiling trace if useful.