默认情况下，vertical 时 panel1 在左、panel2 在右；horizontal 时 panel1 在上、panel2 在下；fixedpanel 配合 splitterdistance 控制固定边，子控件需设 dock=fill 才随分割拖动自适应，高 dpi 下应避免硬编码像素值。
SplitContainer 的 Panel1 和 Panel2 到底谁在左/上？
默认情况下，SplitContainer 的 Orientation 是 Vertical，这时 Panel1 在左，Panel2 在右；设为 Horizontal 时，Panel1 在上，Panel2 在下。这个顺序不能靠拖控件改，只能靠代码或属性面板调 Orientation 和 FixedPanel。
常见错误是把控件拖进 Panel1 后发现位置不对，其实是方向没设对，或者误以为 Panel1 总是“主面板”——它只是编号靠前，没语义优先级。
-
FixedPanel设成Panel1或Panel2才能固定某一边尺寸，否则拖动分割条时两边都会缩放 - 如果想让左边固定 200 像素、右边自适应，就设
FixedPanel = FixedPanel.Panel1，再设Panel1MinSize = 200 - 直接改
Panel1.Width或Panel1.Height无效，得通过SplitterDistance控制分隔位置
拖动分割条后，子控件不自动拉伸？
根本原因是子控件的 Anchor 或 Dock 没配对。SplitContainer 自身会响应大小变化，但里面嵌套的按钮、列表框这些不会自动跟着撑开。
最稳妥的做法是：把子控件的 Dock 属性设为 Fill。比如在 Panel1 里放一个 TreeView，必须设 treeView1.Dock = DockStyle.Fill，否则拖动分割条时它会卡在左上角不动。
-
Anchor也能用（比如Top, Bottom, Left, Right），但容易漏边，Dock.Fill更直观可靠 - 如果 Panel 里套了
GroupBox或Panel容器，那容器本身也要Dock = Fill，再让它的子控件填满它 - 别在设计器里手动拉伸子控件来“凑满”，运行时一拖分割条就露馅
SplitterDistance 和 SplitterWidth 的实际影响
SplitterDistance 是分割条到容器左边缘（垂直）或上边缘（水平）的距离，单位像素，不是百分比。设成 300 就是固定距左 300px，和 FixedPanel 配合才有意义。
SplitterWidth 默认是 6，看起来细，但太细会导致拖拽不灵敏，尤其高 DPI 下可能点不中。加到 8–10 更实用，不过别超过 12，否则视觉割裂感强。
- 修改
SplitterDistance会立刻重绘，但若此时FixedPanel未设置，两边 Panel 会按比例缩放，结果可能和预期不符 - 在窗体
Load事件里设SplitterDistance比在构造函数里更安全，避免初始化顺序问题 - 不要监听
SplitterMoved事件去反复更新SplitterDistance，这会引发递归重入，导致界面卡顿或崩溃
为什么双屏/高 DPI 下分割条错位或拖不动？
这是 WinForms 缩放适配的老问题。SplitContainer 在非 100% 缩放下，SplitterDistance 的像素值会被系统换算两次，一次是逻辑像素→设备像素，一次是反向映射，容易失准。
解决办法不是硬调数值，而是避开像素依赖：用 Panel1MinSize + FixedPanel 组合，或者在 Resize 事件里按比例重算 SplitterDistance。
- 在
Form构造函数里加this.AutoScaleMode = AutoScaleMode.Dpi，比Font更稳 - 如果必须动态设距离，用
SplitContainer.ClientSize.Width * 0.3这类比例式，而不是写死 240 - 测试时一定要关掉“允许 Windows 尝试修复应用缩放问题”这个兼容性选项，否则行为不可预测
拖动逻辑看着简单，但 FixedPanel、Dock、DPI 缩放三者一叠加，出问题时往往只改一个地方压不住，得一起看。
