1. 为什么“设计规范”必须同时绑死uniapp和即时设计
先说一个我见过太多次的场面。设计师在即时设计里排了一套特别精致的界面，圆角、阴影、字号都调得漂漂亮亮，交付给前端时还贴心地标好了px数值。结果前端用uniapp开发完，在H5里一跑，标题字小了、间距松了、按钮在安卓上变形了，设计师看了当场血压拉满。
问题不在谁不专业。两个工具之间天然存在“表达层”和“实现层”的断层：即时设计给你的是绝对像素坐标下的视觉稿，而uniapp做的是跨端动态渲染，同一个数值在iOS、Android、小程序、H5上的表现根本不可能完全一致。如果没有一套两边都认的“共同语言”，那协作就是无休止的返工。
所谓“通用前端应用设计规范”，本质就是把这种共同语言固化下来。它不只是一份设计文档，也不是一份代码规范，而是一张横跨设计与开发、从视觉稿延伸到渲染结果的“翻译协议”。协议里写清楚：颜色怎么定义、字号怎么梯度化、间距怎么栅格化、组件怎么模块化、多端差异怎么兜底。一旦这套协议在即时设计里落地为设计变量，在uniapp里落地为主题变量、全局样式和通用组件，双方就都有据可依了。
2026年这个时间点不是噱头。现在的工具链已经变了：即时设计支持了变量引用、多端预览，甚至可以在设计稿里模拟暗黑模式；uniapp也把vue3+ts作为默认姿势，CSS变量、动态主题这些能力都不是问题。也就是说，以前要人工对表才能实现的规范体系，现在工具层面已经给了我们还算顺手的接口。本文就把这套规范和落地路径完整拆开，适合正处在“设计稿到跨端应用经常走样”这个阶段的小团队参考，也适合想从源头统一设计语言、减少沟通损耗的同行抄作业。
1.1 多端碎片化：uniapp给设计稿提出的“格式要求”
只要用过uniapp就知道，它最核心的卖点是“一套代码编译到多个平台”，但这背后有个容易被忽略的前提：不同平台对“同一种样式”的解释根本不一样，比如：
- 导航栏：微信小程序的导航栏是原生渲染的，H5的导航栏是HTML模拟的，App端又可能是用原生组件或者webview渲染的。设计稿里画一条通栏导航，到了小程序里很可能被胶囊按钮挡住，到了App里又可能多出一截状态栏。
- 安全区：iPhone的底部小黑条、安卓的虚拟手势条，占用的区域数值不是固定的。设计稿距离底部10px，真机上可能直接被手势条压住。
- 字体渲染：iOS对字号比较“老实”，安卓在部分第三方ROM里会强制做字体缩放，用户调了大号字体后，固定px的按钮文案直接溢出。
这就意味着，设计规范如果只给出静态的“漂亮数字”，是解决不了问题的。规范里必须明确：哪些数值是绝对刚性的，哪些数值是相对弹性的，哪些位置需要预留安全区。这一点，uniapp项目比纯Web项目要苛刻得多，因为它面向的是不同渲染引擎的“组装拼盘”。
1.2 设计工具与代码之间的“翻译损耗”问题
即时设计输出的视觉稿，天然是绝对世界的表达：一
