R4.09.2library-borne convention设计
约定随实现库分发，靠代码而非文档传播
别名: 库内分发 · implementation library · Material Components
概念解释
Material 真正进入产品的方式，不是设计师读完一份网站，而是工程师引入组件库。约定跟着二进制走：涟漪怎么起、类型比例怎么排、表面怎么叠，默认写在可编译的构件里。这份传播机制叫库载约定（library-borne convention）——惯例的载体是代码，文档只是说明书。没进库的句子，等于没发货。
它解释的不是物理隐喻本身，也不是换皮允许到哪一步。它解释的是：互不相识的应用为什么会「摸起来像同一家」，答案是共享了一份实现，而不是共享了一份阅读作业。
机制
人会走成本低的路。重新实现一个按钮的状态、触摸反馈和可访问性角色，贵；调用库里的按钮，便宜。于是默认行为随着依赖一起进了产品，不经过设计评审也会在。网站上的长文改变不了这个成本结构：读过但没引用的句子，在运行时不存在。
这也是为什么文档与产品会脱节。库的版本、文档的版本、设计稿引用的版本可以是三个数。用户摸到的只有库。设计团队若只维护一份与库脱钩的页面，改的是说明书，不是惯例。惯例的更新通道是发版日志和破坏性变更，不是新的章节标题。
边界
没有官方库覆盖的平台（某些嵌入式、自研渲染引擎、游戏画布）谈不上库载，约定只能靠自建构件或放弃一致性。库被深度 fork、内部打补丁到无法跟随时，分发通道已经断裂，文档更救不回来。纯视觉营销站和一次性活动页若不引入库，本就不应声称在遵守 Material。文档仍然有用：它教人如何选构件、如何主题化；它不替代构件成为惯例本身。
怎么落地
- 把产品依赖的 Material 实现库版本钉死在仓库里，设计稿标注的组件名与库里的符号对齐，而不是对齐某篇网页的插图。
- 设计新增一种控件之前，先在库的目录里找已有构件；找不到再提需求给库，而不是先画一套自绘再「参考一下」。
- 库升级当作设计事件：读破坏性变更，打开受影响的屏幕，而不是只跑编译。
- 验证：抽一个高频构件，在仓库里搜它的类型名或导入路径。搜不到、却在界面上「看起来像」，说明惯例来自临摹而不是分发。再对比当前库版本的图库与产品截图，行为差一截的地方记为文档没进代码。