嘿，这个布局需求在iPad开发里挺典型的，我来帮你拆解下三个方案的优劣势，再给你点实际的选型建议——毕竟选对方案能帮你省不少后期维护的麻烦。

方案1：全Storyboard实现 #

优点 #

• 可视化效率高：拖拖拽拽就能搭出基础布局，不用写一堆创建视图、添加约束的代码，适合快速验证原型或者简单项目
• 预览直观：直接在Interface Builder里切换横竖屏，实时看到布局效果，调试约束冲突也能即时反馈
• 协作友好：设计师或者不擅长代码的同事也能参与布局调整，不用碰代码就能修改界面样式

缺点 #

• 约束冲突排查麻烦：多个视图的自适应布局很容易出现约束冲突，有时候IB的提示不够清晰，排查起来比代码还费时间
• 灵活性不足：如果需要根据设备型号、系统版本做差异化布局，或者有复杂的动态逻辑，IB很难实现，只能靠代码补，但这样就变成混合模式了
• 多人协作易出冲突：大型项目里多人修改同一个Storyboard，Git合并时很容易出现冲突，解决起来非常头疼

方案2：Storyboard与代码混合实现 #

优点 #

• 平衡效率与灵活：用IB搭建基础视图和固定约束，把横竖屏切换的动态逻辑（比如调整约束优先级、重新排列视图）放在代码里实现，比如在viewWillTransition(to:size:)方法里处理
• 减少冗余代码：不用写大量创建视图的代码，只聚焦在动态布局逻辑上，代码量可控
• 调试方便：既可以在IB里看基础布局效果，又能通过代码断点调试动态逻辑，两边互补

缺点 #

• 逻辑分散：新手容易搞不清哪些布局逻辑在IB里，哪些在代码里，后期维护时可能会重复修改或者遗漏
• 仍有合并冲突风险：只要用到Storyboard，多人协作时就可能出现合并冲突，只是范围比全IB方案小一些
• 约束冲突隐患：代码里修改的约束如果和IB里的约束逻辑不一致，很容易出现隐性冲突，排查起来也挺麻烦

方案3：全代码实现（你担心冗余但觉得简单） #

优点 #

• 逻辑清晰可控：所有布局逻辑都在代码里，横竖屏切换的条件、约束调整都一目了然，排查问题直接找代码就行，不用在IB里翻找
• 灵活性拉满：不管是要适配不同设备、系统，还是后期需求变更（比如加个视图、改布局规则），直接修改代码逻辑即可，没有IB的限制
• 协作无冲突：多人协作时不会有Storyboard的合并冲突问题，代码合并更清晰，也更容易做代码Review

缺点 #

• 初期代码冗余：创建视图、添加基础约束的代码确实会比较繁琐，尤其是纯Auto Layout代码写起来有点啰嗦
• 无实时预览：必须运行模拟器或者真机才能看到布局效果，调试周期可能比IB长
• 上手成本：如果不熟悉Auto Layout的代码写法（比如NSLayoutConstraint的链式调用），或者没用过SnapKit这类第三方布局库，上手会有点慢

选型建议 #

给你总结下不同场景下的最优选择：

• 小型项目/快速原型：选全Storyboard实现，快速高效，能很快看到成品效果，适合验证需求
• 中等复杂度项目：选Storyboard+代码混合，用IB搞定基础布局，代码处理动态逻辑，平衡效率和灵活度
• 大型项目/多人协作/需求易变：选全代码实现，虽然初期写代码麻烦，但后期维护成本低，逻辑清晰，还能避免合并冲突的噩梦

另外提一句：全代码的冗余问题其实可以解决，比如用SnapKit这类第三方库简化Auto Layout代码，或者封装一个通用的布局工具类，把重复的布局逻辑抽出来，能大大减少冗余，让代码更简洁。

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