TScrollBox组件可放置子组件最大数量限制及崩溃问题咨询

TScrollBox 不存在官方设定的固定子组件数量硬上限，你遇到的异常、崩溃问题和组件本身的设计容量限制无关，本质是VCL控件的资源开销、Windows系统资源配额、全量子控件遍历重绘逻辑共同导致的瓶颈：

• 如果你放在TScrollBox里的单段轨道控件是TWinControl的派生类，每个控件都会独立占用一个Windows窗口句柄。Windows对单进程的窗口句柄有默认配额限制，且VCL在控件滚动、重绘时会全量遍历所有子控件计算位置、触发绘制消息，当子控件数到3000+时，遍历开销已经会堵塞消息队列，出现绘制错乱、响应卡顿的异常表现；到5000左右时，要么触发窗口句柄分配失败，要么重绘过程出现内存越界、栈溢出，直接导致程序崩溃。
• 你换到64位XE2编译后问题没有消失也符合这个问题的特征：64位编译仅扩展了进程可用的内存地址空间，既不会提升单进程的窗口句柄配额，也不会优化VCL全量子控件遍历的重绘逻辑，自然不会解决崩溃问题。你之前估算的16000个组件承载量，是按纯内存占用算的，完全没算窗口句柄、消息循环的开销，和实际场景的阈值偏差很大。

按改造成本从低到高排序：

• 低成本临时方案：将所有单段轨道的控件替换为TGraphicControl派生的无句柄图形控件
  这类控件不需要独立申请窗口句柄，所有绘制动作都直接在父容器的画布上完成，资源占用比带句柄的TWinControl低一个量级，正常可承载1.5万-2万个轨道单元不崩溃。但这个方案没有解决全量子控件遍历的重绘开销问题，轨道数量再高还是会出现卡顿。
• 高性价比最优方案：放弃“单段轨道对应一个独立VCL控件”的实现思路，改用虚拟绘制模式
  不需要为每段轨道创建真实的控件对象，只在内存中维护所有轨道段的坐标、样式、连接关系等结构化数据，在TScrollBox中放置一个对应总布局尺寸的TPaintBox，在其OnPaint事件中只计算、绘制当前滚动视口可见范围内的轨道段图形即可。这种实现下哪怕轨道段总量到十万级，内存占用和绘制性能都不会出现明显衰减，完全不会触发当前的崩溃问题。如果需要实现点选、拖拽编辑轨道的交互，只需要在鼠标事件中根据当前坐标、滚动偏移量反向匹配对应位置的轨道数据即可，不需要依赖真实控件的消息响应。
• 低代码替代方案：如果不想从零实现虚拟绘制逻辑，可以替换为支持虚拟自绘模式的画布类组件，不需要手动管理滚动、可见区计算逻辑，只需要按组件要求实现对应区域的绘制、交互匹配代码即可。

内容的提问来源于stack exchange，提问作者Alessandro Brolis