约束布局

前四节练的都是 Web 这门手艺：文档流、定位、Flexbox、Grid。这一节换一个世界——原生 App（iOS / Android 手机应用）。手机屏幕比浏览器窗口恶劣得多：尺寸千奇百怪、随时旋转、还能折叠，用户还可能开着老年机大字体模式。于是原生阵营没有照抄 CSS，而是发明了另一套思路：不告诉系统「东西放在哪个坐标」，而是告诉它「谁和谁是什么关系」——离左边多远、和谁对齐、按什么比例——然后让一个会解方程的引擎算出所有坐标。这就是约束布局（Constraint Layout）：iOS 的 AutoLayout、Android 的 ConstraintLayout 是它的两大门派。说白了，CSS 是「你按规则自己排版」，约束布局是「你说关系、机器解几何题」。学完这一节，你不仅多了半张移动互联网的地图，更会看懂一件大事：布局这门手艺，正在从「写坐标」进化到「讲关系」——而这条路，和你前四节学的声明式思想，最后殊途同归。

术语对照：把原生阵营的行话翻译成人话

摆家具的智慧：说的是关系，不是坐标

先把场景里的道理讲透。用坐标描述布局，听起来最精确，其实是最脆的：坐标只对一个特定的房间成立——客厅一换，全部作废。用关系描述布局，乍听含糊，实际最稳：「沙发贴西墙」这句话在任何客厅里都能执行，师傅自己量出「西墙在哪」。不妨这样想：坐标是「答案」，关系是「题面」——答案换个房间就错，题面永远成立。约束布局的全部赌注就押在这：把题面交给系统，答案让它现场算。这不是偷懒，这是把「随环境变化必须重算的那部分工作」从人手里交给了机器——人来写答案，每换一个屏幕就要重写一遍；机器来解题，换一千个屏幕也只是多算一千道题。

为什么手机上「写死坐标」活不过第一周

这套思路不是手机工程师标新立异，是被环境逼出来的。浏览器那边，窗口虽然也能拉大缩小，但多数网页至少横竖一致；手机这边是修罗场。第一，屏幕碎片化：安卓阵营几十家厂商、上千种机型，4 寸小屏到 13 寸平板都有，你按自己那台手机摆好的坐标，到了别人手机上不是挤成一团就是空出一大片。第二，旋转：手机一横过来，宽高互换——写死的 x/y 瞬间全部作废。第三，折叠屏与分屏：屏幕还能在运行中「变大」，布局必须实时重排。第四，最容易被忘的一条：动态字号——老人把系统字体调到最大，一段 16sp 的文字直接胖成 24sp，你写死的容器高度立刻装不下，字被拦腰截断。说白了，手机的屏幕不是一张定死的画布，是一块随时变形的橡皮泥——在橡皮泥上钉钉子（坐标），怎么钉都得掉。

顺带把两个原生世界的度量单位收进工具箱：dp（density-independent pixel，密度无关像素）管「物理长短」——屏幕再密，100dp 的按钮在肉眼里的宽度基本一致；sp（scale-independent pixel）管「文字」——它额外跟着用户的字号设置缩放。翻译成人话：dp 量布料，sp 量字——布料不随用户心意变，字要随。这两个单位的分工，本身就是「为多变环境而设计」的一部分：单位层面已经把「密度」和「字号」两个变量接走了，布局层面再把「尺寸和方向」接走，剩下的才交给开发者。

三条族谱：从 AutoLayout 到 ConstraintLayout，再到声明式新秀

约束布局的思想史有三站。第一站，1997 年：华盛顿大学的研究者发表了一个叫 Cassowary 的约束求解算法——名字取自一种不会飞的大鸟「食火鸡」，它干的活儿是把一堆线性等式和不等式（「A 的左边 = B 的右边 + 间距」「A 的宽度 ≤ 屏宽」）快速解出唯一答案，本来就是给界面布局设计的，但此后十几年没人真正用它发家。第二站，2012 年：苹果在 iOS 6 里推出 AutoLayout，引擎正是 Cassowary——开发者在界面设计器里用鼠标拖线，把「这个按钮的顶对齐那张图的底加 8 点」这类关系画出来。2016 年，谷歌给安卓推出 ConstraintLayout，同样以 Cassowary 一脉的求解器为心脏，目标直指安卓当时的顽疾（下一节讲）。第三站，2019 年起：SwiftUI、Jetpack Compose、Flutter 这批声明式框架登场，表面上看约束「失宠」了——它们主推的 Row/Column 明明是 Flexbox 的思路。约束思想死了吗？恰恰相反——它被拆开吸收进了黑盒，这节最后一节专门讲这场「落幕与转世」。先记住族谱：算法（1997）→ 两大门派（2012/2016）→ 声明式转世（2019 后）。

正史之前：两位没写进族谱的前辈

族谱正文之前，其实还有两位前辈值得点名。苹果那边叫 springs & struts（弹簧与支柱，官方名 autoresizing mask）：父容器变大小，子元素按预设的「弹簧」（可拉伸）和「支柱」（间距定死）伸缩——好比折叠晾衣架：只能整体放大缩小，表达不了「A 跟着 B 走」的横向关系。安卓那边是 RelativeLayout（相对布局）：能说「这个元素在另一个下面、和父容器右对齐」，比线性排列强多了，但它的「关系」是一份写死的预设菜单——只能贴边、对齐，算不了比例、配不了权重，复杂版面照样得嵌套。两位前辈的共同短板一句话：它们只回答「我怎么跟着父容器变」，答不了「兄弟元素之间怎么协商」。约束布局的革命性恰恰在这：把「任意两个元素之间都能立关系」写成了通用语法——前辈是「只能跟队长说话的队员」，约束系统是「队员之间随便结对」，协作能力直接差了一个维度。

约束是一条方程：布局原来是解应用题

现在拆开引擎盖看原理，你会发现没有玄学，全是中学数学。每条约束本质上就是一个方程：假设每个元素有四个未知数——左边界 x、上边界 y、宽 w、高 h，那么「按钮左边缘 = 父容器左边缘 + 16」是方程；「标题的底 = 图片的顶 − 8」是方程；「卡片宽 : 高 = 16 : 9」也是方程。一个界面几十个元素、上百条约束，就是上百个方程组成的方程组。求解器（Cassowary 及其亲戚）拿到方程组，噼里啪啦解出所有未知数——每个元素的 x、y、w、h 全部落定，布局完成。打个比方，这就是考试里的应用题：题目给条件（约束），你列方程求解（布局引擎），最后写答案（渲染坐标）。CSS 那边是「规则引擎」——按属性一步步推；约束这边是「数学引擎」——条件一齐丢进去，一次解出全局。两种引擎的差别后面还会回来讲，这里先把「布局 = 解方程」这个心智模型钉死。

拿一组最简单的数字走一遍，彻底祛魅。设屏幕宽 400（单位随便）：「按钮 A 贴屏幕左边」→ 方程 A.x = 0；「按钮 A 贴屏幕右边」→ A.x + A.w = 400；两条联立，解出 A.w = 400——A 的宽度被这两条位置方程顺带撑了出来。这就是 0dp「吃满空间」的数学真相：不是「宽度 = 屏幕宽」这条指令，而是两条位置方程联立求解的副产品。再看「按钮 B 在 A 右边 16」→ B.x = A.x + A.w + 16——三行方程，B 应声落位。整个界面不过是把这套联立放大到上百行。说白了，考试做应用题的直觉在这完全适用：方程多不怕，怕的是缺条件和打架——两种怕法，恰好就是下一节的两种病。

欠定与超定：约束系统的两种病

既然是方程组，就会得方程组的病，一共两种，都要认得。病一：欠定（ambiguous，歧义）——方程比未知数少，解不唯一。你说「按钮贴左边」，横的方向定了，竖的方向只字未提：它可以在顶、在底、在中间任何一个位置——元素「飘」了。Xcode 会直接警告 Ambiguous Layout，Android Studio 会喊 missing constraints。病二：超定（conflict，冲突）——条件互相矛盾，无解。「按钮贴左边、贴右边、宽 500」，而屏幕总共才 400 宽——三个要求谁也不让谁，系统只能报错，或者悄悄打破其中一条硬塞给你一个结果。就像考试应用题：条件不够做不出来，条件打架也做不出来——两头的报错方式还不同，欠定是「不吭声地飘」（开发期看着没事，真机上就漂移），超定是「当场翻脸」（调试器里红字一串）。排错时先分清是哪种病：飘，补约束；红，删矛盾。

每个元素两条锚：完整约束的口诀

欠定的解药是一条口诀：每个元素，水平一条锚，垂直一条锚，位置才有着落。「水平一条」可以是「左边缘挂在某物上」，也可以是「左右都挂（宽度被撑开）」或「水平中心对齐某物」——总之水平方向的自由度被锁死；垂直同理。这是约束布局第一天的纪律，就像电工接线前先断电——不守它，后面的招式全是空中楼阁。Android 里最常见的翻车现场：拖了个控件进布局，忘了挂垂直约束，开发工具好心给个默认位置，模拟器上看着挺好——换个字号、换个密度，按钮原地消失或飞到角落，查半天才发现是「垂直自由度」从第一天起就没锁。把这个教训浓缩一下：界面布局上「看着对」从来不等于「约束对」——看着对可能只是默认值碰巧站对了位置，而默认值不跟屏幕走，约束跟。

安全区：把刘海和手势条写进方程

「贴父容器边缘」这句约束，在全面屏时代还藏着一层设定：屏幕的「边缘」不止物理边一条。顶部有刘海或挖孔遮住一块，底部还有一条手势条（那条小横线）——按钮真贴着物理边放，要么被刘海切掉一角，要么被手势条挡住点不中。于是两个平台都引入了安全区（safe area）：系统在屏幕里划出一圈「保证不被遮挡」的内边界，你的约束默认挂的是这条内边。翻译成人话：师傅量客厅时，自动把暖气片占的墙和门口留的过道先扣掉，家具「贴墙」贴的是扣完之后的墙——家具不用知道暖气片在哪，师傅知道就行。这个设计还有更深一层的好处：「危险区域」的复杂度被一次性封装进了系统层——iPad 分屏、MacBook 的刘海屏、手表的圆角屏，全是同一套机制在兜底；控件自己只管贴边，永远不用写「如果是刘海屏就往下挪 44」。界面适配环境的脏活，又一次交给了系统——「讲关系、别讲坐标」的原则，连屏幕边缘自己都遵守了。

leading 与 trailing：跟阅读方向走的锚

还有一对术语必须交代，因为安卓约束属性里全是它们：layout_constraintStart_toStartOf 里的 start 不是「左」，是「行进方向起点」（leading，行首）；对应的 end 是行尾（trailing）。为什么不用 left / right？因为世界上不止一种阅读方向：阿拉伯语、希伯来语从右往左读，界面一切到 RTL 模式，start 自动换到右边。挂 start 锚的界面切到阿拉伯语，整页自动镜像——标题跑右边、返回箭头掉头，代码一行不改；iOS 的约束同样有 leading / trailing 版本，两家在这件事上出奇一致。这和 § 3.4 讲 Grid 的逻辑方向是同一件事在两个阵营的再次现身：布局词汇认「阅读方向」，不认「物理左右」。说白了，跟师傅交代「家具贴进门那一侧」，别说「贴东墙」——房子换个朝向，进门那侧永远指得清，东墙未必还在原位。新人最常见的失误就是用 left/right 思维写约束，阿拉伯语版上线那天才发现整页镜像不了，改回来全是体力活。起步就立规矩：锚挂 start / end，把 left / right 从字典里删掉——这是原生世界里「一开始就写对」成本最低的一条。

尺寸三态：固定值 / wrap_content / 0dp

位置讲完讲尺寸。原生世界里元素的大小有三种活法，和 CSS 的三件套惊人地对应：固定值（写死 200dp）——雷打不动，对应 CSS 的固定像素；wrap_content——按内容长，「装多少占多大」，对应 CSS 的 auto / fit-content，纸箱按货；0dp（Android 叫 MATCH_CONSTRAINT）——尺寸交给约束系统，「在约束允许的范围里能吃多大吃多大」，相当于 CSS 的 fr：吃剩余空间的那一挂。0dp 是三态里最微妙也最有用的：它自己没有尺寸，全靠约束喂——左右各挂一条锚，宽度就被撑到两条锚之间的全长；配上下一节的权重，还能按比例分蛋糕。一个常见坑顺带立此存照：0dp 元素如果约束没挂全（只挂了一边），求解器没有信息，宽度直接算成 0——元素神秘消失，十有八九是 0dp 饿死的。iOS 阵营没有 0dp 这个写法，但同一思想长在别的属性上：宽度设成「等于另一元素的宽 × 倍数」「大于等于某值」，同样是把尺寸交给关系去定。

链与权重：约束世界里的 flex-grow

三个按钮想平分一行——CSS 里你写 flex: 1，原生这边叫链（chain）：让一组元素首尾相连（第一个挂父左、最后一个挂父右、中间的手拉手），它们就成了同一条链上的兄弟，共同瓜分这条链的空间。链有三种队形：spread（默认，均匀散开）、spread_inside（两端贴死、内部均分）、packed（抱团，整体可以再配 bias 挪位置）。链上还能加权重（weight）：三个按钮权重 1:1:2，剩余空间就按这个比例分——其实就是§ 3.3 学过的 flex-grow，连算法带心智模型原样照搬。这里值得停一秒品一品：两个平台、两套术语、一个思想——「把空间按权重分给排队的元素」这件事，凡是活下来的布局系统都长出了几乎一样的器官。学布局学到这个层面，你会开始认得出器官，而不是背物种：见到任何新框架，先找它的「弹性分蛋糕」在哪——多半一眼就找到。

链的 packed 队形单独说一句，因为它和 bias 组合出了一个高频件：一行按钮想「整体居中、彼此只隔 8dp」——链设 packed、间距 8、bias 0.5，按钮们手拉手站正中间；改需求「整体靠右」？bias 拨到 1.0，一秒搬家。这就是约束系统的味道：队形是声明出来的，不是算出来的。CSS 里你写 justify-content: center 配 gap: 8px，链这边是 packed 配间距——两边都一行搞定，但底下一个是规则推演、一个是方程求解，两条路殊途同归到同一个版面。工具不同，「声明意图」这个内核，第三次撞衫了。

guideline 与 barrier：看不见的墨线和排面线

两个高级小工具，都是「画一根线，别的东西挂上去」。guideline（辅助线）是一根自己不显示、只当锚用的线：可以定在「父宽的 40%」处，也可以定死「离左 72dp」。想做一个左栏固定 40% 的两栏界面？画条竖 guideline 在 40%，左栏挂线左、右栏挂线右——像不像装修师傅在地板上弹的粉笔线？§ 3.4 讲 Grid 的命名线时你见过这位亲戚：都是「先立一根有名字的线，让内容对线入座」。区别在于 Grid 的线生在轨道系统里（先分格子再谈线），guideline 是独立的散兵线（想画几根画几根，互不相干）。barrier（屏障）更聪明：它是一根会动的线，位置由一组元素的边缘实时决定——比如「这根屏障 = 一排输入框里最靠下那条的底边」。经典场景：表单里三个输入框长短不一，提交按钮想统一对齐「最低那个输入框的下方」。好比一排货架的排面线——不管哪件商品今天凸出来，排面线永远跟着最靠前的那件走。不用 barrier 的写法是「按钮对齐第三个输入框」——第三个输入框哪天变短了，布局立刻露馅。用 barrier，等于把「对齐一组的边」这件需求原原本本交给了系统。

宽高比与 bias：比例和偏置两件小工具

两个一句话工具。宽高比（dimension ratio）：声明「宽:高 = 16:9」，一边定了另一边自动按比例出——视频卡片、头像、封面图的标配写法。它最搭的搭档是 0dp：宽 0dp 吃满约束、高交给比例，一张「多宽都行但永远 16:9」的卡片就成了。这就是照片冲印的规矩：5 寸照片的宽高比是死的，你只决定冲多大，另一边比例说了算。bias（偏置）：当元素两边都有约束（比如左挂父左、右挂父右）但宽度只有 wrap_content 时，剩余空间怎么分？默认对半（0.5 居中），bias 0.3 就往左偏三成。像拔河绳上打的那个结——绳子两端钉死，结的位置由两边的拉力比决定，bias 就是那个拉力比。这两件工具单独都简单，合起来能拼出「卡片按 1:1、整体靠左 70%、下面留空」这类杂志级版面——约束系统的表达力，靠的就是这些小而正交的零件。

优先级与 CHCR：冲突时谁让路

方程组打架了怎么办？约束系统给了文明的解决方案：优先级。每条约束带一个等级，iOS 里是 1~1000（1000 是 required，必守；其余是 optional，可以商量），安卓 ConstraintLayout 里也有类似的强度机制。求解器先满足所有必守约束，再把 optional 的按优先级从高到低尽量满足，实在不行牺牲低优先级的。这好比会议室排座：坐不下时不是全体重新分配，而是按既定规矩有人让、有人不让——规矩先于冲突写好，冲突来了照章办事。

优先级思想最漂亮的应用是 iOS 的 CHCR 两兄弟：Content Hugging（内容抱合力——「别拉长我，我按内容长就够了」）和 Compression Resistance（抗压性——「想挤我？先看看我的抗压优先级」）。经典场景：一行里放「用户名」和「余额」两个标签，窄屏装不下，谁断行？答案由抗压优先级决定：余额是数字不能断，抗压设 751；用户名可断，设 750——于是系统永远先截用户名，账目数字寸步不让。说白了，CHCR 就是给内容发了两张「声明书」：一张说「我多不情愿被拉长」，一张说「我多不情愿被压扁」。两张声明书的优先级，就是这个元素在拥挤局面里的性格。

goneMargin：元素请假了，间距听谁的

一个很有生活感的小机关。界面里常有「条件显示」的元素：会员卡区域，普通用户不显示。它一隐藏（gone），按常理它占的地方和边距都该消失——可有些场合你又希望「它不在时，上下两个元素挨得更近一点」，或者相反「它不在时也保持原来的通道」。安卓给了 goneMargin：一条专门的边距，只在对面元素隐藏时生效。好比办公室里的请假牌：工位还在，但请假期间过道宽度按新的规矩量——规矩提前写好，人走不走都井井有条。这功能小，但它代表的思路不小：可见性也是一种布局状态。约束系统把「在/不在」做成了方程里的变量——元素 gone 时，与它相关的约束自动失效、边距自动切换，整条方程组重解一遍，其余元素各就各位。没有这套机制的年代，「一个元素隐藏、其他元素跟着挪」要靠人肉 if-else 改布局，代码又臭又长还爱出 bug。

圆形定位与虚拟帮手：circular / Group / Flow

三个进阶小件，认个脸就好。圆形定位（circular positioning）：不挂边了，改挂「以某点为圆心、转多少度、半径多少」——像挂钟表盘：表盘中心定了，十二个刻度各自报「角度 + 半径」。悬浮主按钮一点、一圈子按钮绕着它炸开的那种辐射菜单，就是它。Group（组）：把几个元素编成一队，统一控制显示隐藏——队里单个元素的位置约束一点不动，Group 只当可见性的遥控器，就像车间班组长只管点名，不管谁站哪个工位。Flow（流式）：给约束容器补上「自动换行」的能力——一排标签放不下自动折到下一行，行为酷似 § 3.3 的 flex-wrap、§ 3.4 的 auto-fill。这三个小件合起来说明一件事：约束系统不是只有「方程」这一个底层件，在它上面照样长出了「换行、编组、极坐标」这些上层便利件——底层是数学，上层是工具，分工清楚。你以后遇到任何新控件，都可以先问一句：它是新的底层机制，还是老机制包的一层糖？这个问题能帮你把任何框架的文档读薄一半。

综合施工：一个登录页的约束全过程

工具都齐了，像 § 3.4 那样完整施工一遍。需求：登录页——顶部 logo、中间账号和密码两行输入框、底部登录按钮；字号拉到最大也不乱。第一步画草图圈元素：logo、账号输入框、密码输入框、登录按钮，四个元素，一眼扫完。第二步从主内容向外辐射定锚：账号输入框是主心骨——左缘挂「父左 + 24」、右缘挂「父右 − 24」，横竖两条锚一步到位，宽度顺带被撑满（0dp 的经典用法）；密码框左右同款挂父、顶挂「账号的底 + 16」；logo 水平中心对齐父中心、底挂「账号的顶 − 32」；按钮左右挂父、顶挂「密码的底 + 24」；最后整页在垂直方向留点余量，用 bias 稍往上提，免得内容沉底。第三步翻译成安卓的写法（认脸即可，不必背诵）：

<EditText
    android:id="@+id/account"
    android:layout_width="0dp"
    android:layout_height="wrap_content"
    app:layout_constraintStart_toStartOf="parent"
    app:layout_constraintEnd_toEndOf="parent"
    app:layout_constraintTop_toTopOf="parent" />

读一遍：宽 0dp 交给约束，左右两条锚把它撑到父宽减 48；高 wrap_content 按内容（输入框的标准姿势）。第四步验三种病：每个元素横竖各查一条锚（没有飘的）；没有互斥约束（没有红的）；0dp 的左右锚都挂了（没有饿死的）。第五步换环境压测：系统字号拉到最大——输入框 wrap_content 自动长高，下方元素被约束链一路自动下推，整页依然成立。说白了，整个过程的心法和 Grid 施工一模一样：先草图、再定锚、后细节、最后压测——图纸思维一点没变，只是语法从轨道换成了方程。这也是这一章反复验证的结论：布局工具会换代，「先把结构想清楚再动笔」这门内功永远通用。

拍平嵌套：约束布局的性能账

回到 2016 年谷歌为什么非要做 ConstraintLayout。安卓早期的布局三件套是 LinearLayout（线性排）、RelativeLayout（相对摆）、FrameLayout（叠着放）——各有局限，复杂界面只能容器套容器：外层 LinearLayout 竖排，第二层横排的 LinearLayout 里又各套一个 RelativeLayout……而原生布局的开销和 § 2.4 讲的渲染管线一脉相承：每层容器都要对自己的孩子做一轮测量（measure）和摆放（layout），嵌套一层，测量轮数翻倍——列表页滚动时每个条目都要实时布局，嵌套五六层的条目能把滚动帧率拖垮。ConstraintLayout 的卖点就一句：一层画完——不管多复杂的相对关系，全部用约束平铺在一个容器里，测量从多轮变一轮。这和 § 3.4 Grid 的「嵌套控制在两三层」军规是同一本账：布局深度就是性能账单的乘数，工具可以不同，账本永远诚实。顺带说，这也是「拍平」一词的来历：把洋葱一样的嵌套压成一张平面图——乐高玩家都懂，一座用几十块小粒拼的桥和一块整桥板，结构强度差不多，拼装速度天差地别。

ConstraintSet：一套约束换一套长相

约束还有一个 CSS 做不到（或做得很别扭）的绝活：整套布局作为对象，可以整体替换、还可以带动画过渡。安卓的 ConstraintSet 就是「一张关系清单的对象版」：程序里克隆当前清单、改上几条（比如「详情按钮从右下角改到居中」），然后 transitionTo——界面里的元素会平滑地滑到新位置，像搬家公司把整屋家具按新图纸重新摆位，还自带跟拍镜头。搜索框聚焦时展开、卡片选中时放大成详情页、列表切网格——这类「同一批元素、两套摆法」的连续动画，约束替换是天生强项，因为新旧两张图之间每个元素都有明确的起止坐标，插值动画顺理成章。谷歌后来在这基础上又做了 MotionLayout（把多套约束串成带时间轴的编排，概念上先了解到这即可）——但根子都是那条：布局是数据，数据就能切换，切换就能动画。

声明式时代：约束思想的落幕与转世

故事讲到最耐人寻味的一段。2019 年起，苹果 SwiftUI、谷歌 Jetpack Compose 相继登场，Flutter 更早，它们主推的排版工具是 Row / Column / Stack、HStack / VStack / ZStack——眼熟吗？这就是 Flexbox 的思路（Flutter 干脆直接管它叫 Flex）。于是一个自然的疑问：约束布局过时了？往深一层看，恰恰相反。其一，声明式框架把「解方程」藏进了黑盒：你写 Column { Text(); Button() }，框架内部照样在做「约束向下传递、尺寸向上汇报」的计算（Flutter 甚至把这套协议明明白白写在文档里：父给子下约束，子向父报尺寸）——求解器没有消失，只是从「你亲手拉线」变成了「框架替你拉线」。其二，约束作为高级逃生舱仍在：Compose 里有 ConstraintLayout 库，SwiftUI 里有 alignmentGuide 和自定义 Layout 协议——常规排版用结构化容器，复杂对齐退回约束，两栖作战。其三，也是这一节最想说的一句：AutoLayout 十年教给行业的「讲关系不讲坐标」，已经成了整个行业的肌肉记忆——现代框架敢让开发者只写结构不写位置，底气正是「位置交给系统算」这个约束时代的共识。本质上就是一场接力：Cassowary 把「布局=解方程」变成可能，AutoLayout 把它变成习惯，声明式框架把它变成空气。

CSS 的回礼：锚点定位 anchor()

有趣的是，学习是双向的。约束布局「跟别的元素走」的思想，这些年正在被 CSS 学回去：CSS 锚点定位（anchor positioning）已开始落地——Chrome 率先支持，其余浏览器跟进中。它让一个元素（比如弹出菜单、提示气泡）声明「我的左上角锚在某个按钮的右下角、偏移 8px」，目标按钮挪到哪，气泡跟到哪，还自带「贴边自动翻转」防出屏。这正是约束布局最日常的那类关系：此前 CSS 只能靠 JS 实时测量硬算，或用 absolute + 手动坐标凑合。两大阵营互相致敬的画面到这就完整了：原生阵营从 CSS 学走了弹性容器（Row / Column / Flex），CSS 又从约束阵营学走了「跟元素走」——所谓技术演进，常常就是把隔壁院子的好苗子移栽进自家土里，长着长着就分不清原产地了。

三大体系对照表：CSS / 约束 / 声明式框架

布局篇走到这，三门武功都见过面了，摆一张总对照表收个总：

表的读法：横向看，每个需求在三个体系里各有一个名字——名字是方言，需求是普通话；纵向看，三门体系的差别其实在「你讲到多细」：CSS 讲到属性，约束讲到关系，声明式只讲到结构。通俗地说，这是同一门手艺的三种方言，且方言正在融合——学会用「需求」而不是「写法」记知识，是这一章最值钱的迁移能力。

调试与心法：约束师傅的工具箱

真到动手，两边都配好了「师傅的卷尺」。Xcode 里点开约束警告能直接定位到打架的那两条线，还有一键「升级优先级 / 卸掉约束」；Android Studio 的 Layout Inspector 能把运行中的界面连同所有锚点线投影出来，红的黄的警告一目了然——和 § 3.4 说的 DevTools 网格覆盖层是一个路数：布局系统的复杂度上去了，可视化调试就是标配。谁家的工具能让「看不见的关系」现形，谁家的学习曲线就平缓一半——这个判断标准也送给你：将来评估任何新布局工具，先看它的调试器能不能把内部机制画出来。心法上再送四句口诀：先锚点后细节——先把每件家具的位置锁死，再抠间距比例，顺序反了就是反复返工；从主内容向外辐射——先定账号输入框，logo 和按钮再围着它挂，主心骨定了全局不乱；给元素起好名字——id 叫 submitBtn 而不是 button7，约束挂在对的元素上比什么都强；优先级宁少勿滥——每一条 optional 约束都是一张欠条，欠条多了账本必乱。

排错手册：约束布局六案

• 案情一：元素飞到屏幕角落或干脆消失。欠定——横竖各查一遍锚挂齐了没。开发期看着正，多半是吃了默认位置的碰巧。
• 案情二：调试器红字一串，布局直接作废。超定——找互斥的约束（贴左+贴右+固定宽超屏宽）。删矛盾或降优先级，别硬扛。
• 案情三：0dp 元素薄成一条线或不见。0dp 靠约束定尺寸，锚没挂全就饿死成 0。补齐约束，或这格本来就不该用 0dp。
• 案情四：文字被截成省略号。空间不够时被压——查抗压优先级（iOS 的 CHCR）和容器有没有弹性（0dp/weight），别让文字当冤大头。
• 案情五：bias 死活不生效。bias 只在「两边都有约束、中间有余量」时才有意义。一边悬空谈偏置，等于拔河只有一队。
• 案情六：列表滚动卡顿。条目嵌套太深，测量轮数爆炸。参照「拍平」思路：能用约束一层摆平的，别套三层容器。