Swift入门：Xcode Interface Builder中Auto Layout两类leading约束是否等效？

两种约束写法的差异说明 #

你提到的两种约束写法不完全等价。Auto Layout的约束本质遵循线性规则：
第一项.属性 = 第二项.属性 × 乘数 + 常量
左右项的顺序并非可以随意调换，具体差异如下：

• 约束从属逻辑完全相反
  正常布局逻辑下，作为子视图的标题label的位置，应该由作为父视图的主视图位置决定。写法label.leading = leading符合该逻辑：label作为约束的第一项，父视图作为第二项，明确子视图左边界跟随父视图左边界对齐。
  而写法leading = label.leading将父视图作为第一项，逻辑上变成父视图的左边界由子视图label的左边界决定，直接颠倒了父子视图的从属关系。这也是IB自动生成反向约束后，你会遇到卡顿、布局偏差的核心原因：父视图位置绑定到子视图后，会触发IB循环计算布局，甚至生成大量多余的冲突约束。
• 常量计算逻辑相反
  如果需要配置左内边距，正向约束的调整逻辑符合直觉：label.leading = leading + 30就代表label距离父视图左边界30pt。如果是反向约束要达到同样效果，需要写成leading = label.leading - 30，和正常布局认知完全相反，很容易出现数值配置错误。
• IB自动适配逻辑差异
  IB在自动补全缺失约束、校验约束合法性时，会优先基于约束第一项的视图层级做判断。反向约束会让IB误认为父视图的位置需要由子视图推导，会不断尝试生成额外约束补全子视图的位置，最终触发大量重复计算导致卡顿，甚至运行时出现布局偏移。

问题修复方案 #

• 配置约束时优先从子视图向父视图拖拽，不要反过来从父视图往子视图拉，从源头避免约束第一项顺序错误
• 遇到IB自动生成的反向约束，直接删除后手动添加子视图到父视图的正向约束即可
• 不确定约束是否反向时，可以在约束的尺寸检查器中查看约束的第一项、第二项顺序，确保子视图为第一项、父视图为第二项即可。

内容的提问来源于stack exchange，提问作者jeremy ryner