前几天发了一篇帖子《我在团队内部提倡禁用 css margin》，没想到引起了巨大的反响，基本都是持反对意见，给我都整懵逼了，后面仔细思考一下是我的问题，我应该写的再详细一些，并且筛选一下读者，因为我需要保证读我文章的人都能看懂。所以
- 如果你们团队没有购买figma、motiff、masterGo等设计工具，请滑走。
- 如果你们团队没有购买研发模式，请滑走。
- 如果你认为你们的设计团队水平不行，没有自己的设计系统，组件库，请滑走。
- 如果你们团队认为 js 比html css重要，请滑走
- 如果你对设计工具没有基础了解，请滑走
- 再次确认你看懂了，理解了，符合了前面 5 点，如果你没有看懂或者不同意我前面 5 点，请划走，因为你大概率也是看不懂我下面要说的内容的。
如果以上条件你都已经满足，那么恭喜你，我会认为你所在的团队是一个优秀的团队，是一个重视用户体验，设计交互的的团队。因为我从事前端开发就是因为我喜欢写网站，喜欢写高质量的网站，而这是国内前端开发非常不重视的地方。就拿掘金举例，字节出品，国内技术论坛龙头。甚至连og和tab支持都做的贼差。
有人说我上一个例子太简单，那么我现在从figma社区里面找一个页面音乐app的页面 复制出来查看配置，发现最外层没有使用自动布局
这会导致一个问题，就是这个稿子是没有办法宽度自适应的，比如我拖拽修改宽度，里面的内容会错位，比例变得不正确，我不确定这个原作者是不是本意就要宽屏展示成这样，因为我也没必要因为这个就去联系人家。但是本次例子中，我假设这位设计师期望不是这样的。
如果你作为前端开发拿到了这个稿子，你会怎么写代码，里面的内容是固定宽度的还是撑满宽度？是不是需要去找设计同学确认一下？徒增沟通成本。
如果你说这个不用二次确认，肯定是宽度撑满啊，一看就知道。那么你就是经验主义了。明明设计同学可以在设计稿中画出来一个自适应的，为什么不让他把他的工作做的完美，而需要前端做猜测？
然后我来修改一下这个图层，加上自动布局，里面内容搞成自适应宽度的，效果大致就变成这样
然后切换到研发模式看看标注信息展示效果的差异
在原稿中，我想要知道'moody'到列表区域的间距是多少，我需要先选中一个，然后鼠标移动到另外一个上 首先这个操作就麻烦，每个距离都要手动测量。其次如果出现了图层覆盖的情况，甚至都没有办法选中，这时候不是猜就是要去问，成本就增加了。
然后看一下我修改为自动布局之后的效果 各种信息一目了然，甚至可以从设计稿中看出设计师的想法，你也知道应该怎么组织你的html结构。
所以不要看这个音乐app的设计稿在figma社区中是个高赞作品，但是这个人的设计风格和习惯，在我们公司的设计团队是直接要被打回重做的，没有任何商量的余地。因为这个设计稿无法给研发提供任何有效的信息，也体现不出设计的构思，别的设计同事也没办法复用。对比到前端来说，就好像你的同事天天写绝对定位，你领导会不会干掉他？
接下来我又在社区中搜索了使用自动布局的例子，带你们看下这个稿子
原尺寸
缩小
放大
研发模式 这个设计稿清晰的分组结构是不是跟读了大佬的代码一样赏心悦目？你作为研发你更希望设计交付哪一种呢？
看到到这里，可能有人会说我跑题了，标题说的不要用margin，为什么通篇讲设计稿质量高低的问题？
那么接下来我从代码角度解释为什么不要用margin。
先介绍一下figma的背景知识，figma只有两种布局方式，自动布局和相对定位。
自动布局等价于flex box
相对定位等价于relative absolute
你可以把设计师当作前端开发，区别是他们只会用DreamWeaver（年轻的朋友自行百度）写html。
那么他们可以只用这两种方式写html，我们为什么不可以？并且html分组结构应该尽可能的和设计稿保持一致。
此时又有人要说了，他们写他们的，我们写我们的，为什么要做到一模一样？他们只会用这两种是它们菜，我厉害，我有一百种写html的技巧。
这就是涉及到了可维护性的问题。
我说一个我的真实经历，一个页面顶部栏，第一行面包屑导航，第二行是页面标题，第三行是页面操作按钮，他们间距是16px，于是我给每个元素设置margin-bottom： 16px，判断是最后一个就margin-bottom：0。后面需求迭代，要求在标题下面4px加一个页面副标题。页面操作按钮还是距离上方也就是副标题还是16px。然后我就给主标题bottom改成了4px，然后插入一个bottom为16的副标题，完美实现需求。
然后需求又迭代了，有的页面不展示副标题，有的展示。此时我就炸了，因为我不知道主标题的margin-bottom到底要写多少了。是写一段复杂的css表达式还是通过js来计算呢？哪样都很脏。
然后我去找设计咨询，让他给我详细的介绍了一下使用自动布局分组想法，然后我按照他的思路用flex重构了一遍。就可以完美的解决需求了。
经过这次事情之后，我就养成了看设计稿的时候注意看分组结构的习惯，后面设计走查需求给我提的问题就少了很多。要不然以前经常给我提bug，这边少了4px，那边多了8px，这个高度少了1px之类的问题。
如果，你们的设计团队是由追求有抱负有能力的设计团队，那么你甚至可以直接让设计帮你改html。因为figma的图层包含了很多信息，通过插件api遍历图层信息，只需要无脑的写规则，是可以把设计稿转代码的，目前figma插件社区有非常多的design to code 插件，都是这个原理。把图层信息一比一转为代码。因为我之前也写过一个。我非常了解design to code 的细节。
其实我这个插件对设计稿还原度已经很高了，我自认为效果不输 figma 插件社区的头部几个，但是我没有发布，因为我知道这种插件没用。因为设计稿的质量不高，生成的代码质量只会更低。
对于desgin to code 感兴趣的朋友可以直接去看figma插件文档，里面对每个字段都有详细的描述，比如
比如这个字段就代表css中的flex grow。
这个字段就代表flex 主轴对其方式。
最后点题结束，为什么不用margin，因为设计稿没有margin，为什么设计稿没有margin？因为figma不支持，为什么要跟设计稿保持一致？因为这样可以减少沟通成本，缩短开发时间。甚至未来的某一天可以真正的直接使用设计稿生成的代码。