一、概述   作为一个码农，在成长过程中总是有各种各样的挑战，面对这些挑战很对人又不知该如何解决。而作为成长方向上为数不多的有光明前途的平台设计者，可以拥有更多的“机会”，也是团队中可以指引整体发展方向的“引导者”，在组织中拥有“重要”的地位。   当然先成长为一个优秀的“开发者”对升级成为一个平台设计者会更有帮助，以前的文章也有探讨过研发思维的建设，传送门在这里 码农进阶中的思维变化。   回归正题，多数程序员成长过程中经常会遇到不知怎么将一个很好的东西变成高大上的产品的问题，或者说不知道该更方便的提供/邀请给其他人使用，这里介绍平台化设计思维或者说方向，可以给大家提供一个思路。 二、定义  平台：它是一个基础设施，可以提供 “资源”、“交流”、“服务”等内容，并制定完善的规则，使各种角色的用户可以制作或者获取到特定的内容。 三、如何拥有平台化思维 3.1、为啥要做“平台”   这里我们先探讨“如何拥有”平台化思维，让我们先有个潜意识的就会往那边想，至于“如何设计”，我们下一章节讨论。   为何我这里说“我们先有个潜意识“，是因为我发现日常工作中很多能力强的小伙伴其实都有不错的”研发能力“、”效能思维“、”行动能力“等，然后工作中遇到问题后开发出来了一个”工具“提升了自己的开发效率或者沟通效率，但是却止步于此，比如一个调试工具、一个多端编译工具、一个上传工具等，这些“工具”都有一个普遍的特点，那就是：“单向服务无组织规则”、“功能共享使用者却无法约束”、“生产的数据不共享”、“即使开源也得不到发展”，因此我们要做“平台化”，建立一个基础设施，作为一个“平台”，上面的用户(内容提供者、内容使用者)可以有机的组织到一起，使服务更加流畅、用户各司其职、信息共享更加方便、发展更加迅速，那么如何建立这种“平台化思维”呢，我这里有一个简单的方法-“两步七问”，即：   第一步：规划，时刻谨记我们需要成长和成果，因此我们需要一些更耀眼的“内容”    ●要不要功能更强大一些；    ●要不要推广更广泛一些；    ●要不要做成独一无二(一定范围内)；   第二步：落地，判断能不能做成“平台”    ●可以共享使用功能和数据吗？    ●可以让更多人来自主“生产”内容吗？    ●需要统一管理用户和使用规则吗？    ●需要有更多人来一起发展吗？   以上要时刻提醒、锻炼自己，形成一定的思考习惯，在做之前先“思考”，不然遗忘或者没这个想法，那自己设计开发的东西就发展不起来，甚至可能启发其他人并被占先； 3.2、平台化思维如何建立   上面的3.1小章节只是用来让大家时刻谨记“要不要”和“是否适合“的，接下来我们思考平台要做成什么样，也就是“平台化”的“战略目标”； 这里简单画了一个思维导图，大家看起来可以更加直观。 [图片] 3.2.1、定位   对应图里的”解决什么问题“，也就是我们这个”平台“是用来做啥的，是个”工具平台“、”电商平台“，还是”管理平台“、”娱乐平台“，有了目标才能规划功能，这里简单罗列了几个方向。   需求：范围较广，比如来自产品、研发、测试等等；   效率：提高服务、内容生产的效率，如商城、后台管 理等；   降本：降低了”工作内容“的成本，如开源社区、工具类平台等； 3.2.2、角色   角色即使用此平台的所有构成者的身份，粗略划分为“内容使用者”、“内容提供者”、“中心化服务”，真实用户又可以划分的更加细致，比如后台管理员、会员等级1、会员等级2、普通会员等 3.2.3、组织   组织即平台通过一定的“规则”使所有使用者、内容形成一定的规范，可以形成功能闭环，不同部分各司其职，共同组成了一个“平台”。我们可以这样假设，现在有一堆人、有不同的需求，但是“人”能够去哪、“看”到什么东西、“制作”出什么东西、如何“交流”，这都是零散的、独立的，是个无效、无意义的“组合”，只有通过一定的“规则”“组织”起不同的部分，提供一个平面上，“用户”可以到不同的“地方”，“看”或者“制作”不同的“内容”，这样才能性能一个有效的“系统”。所以一个“平台”需要提供两方面内容：“制定规则”、“提供基础服务”。 3.2.4、发展   一个“平台“若不发展，迟早要没落，要想发展，那就需要提供“更多功能”吸引“更多人”来使用，“更多人”来提供“更多功能”。简单理解就是用户更多、开发更多，那么从一个平台来说，在不谈主动推广，只探讨自然生长的情况下，如果做到“更多人”来开发呢？现在有个比较好的模式就是“生态”，开放出去一部分能力，让更多的人基于“开放”去制作更多的“内容”和”功能“，类似“插件”。这些”插件“越来越多，功能越来越强大，使用的人也就越来越多。 四、如何设计一个平台  上面已经讲了“战略”，接下来我们思考“战术”，即一个平台该“怎么做” 4.1、公式 [图片]   为了方便大家的使用，简单总结了一个公式(大家可以一起来完善它)如上，这里简单介绍一下：    ●“角色A和B”：用户    ●“可以”：权限    ●“动作”：规则    ●“内容X”：数据    ●“越来越多、很多”：生态    ●整体表达：需求 4.2、思维导图   为了方便大家理解，我们还是画个图 [图片] 4.2.1、定位   思考方向主要有：    ●用途，提供给什么人什么服务，大方向上制定目标    ●发展方向，细分市场，提前做好规划    ●竞争对手，对比竞对，思考优势劣势 4.2.2、角色   尽可能多的争取到更多的用户，划分出各种角色，后续可方便规划“需求”、“规则” 4.2.3、规则   可分为如下的内容(粗略)：    ●用户管理：包含登录、注册、权限等    ●内容管理：包含制作、存储、删除、获取等    ●数据管理：包含统计等    ●业务逻辑：包含使用规则、功能服务逻辑、流程逻辑等 4.2.4、生态   “插件”的设计规则：    ●准入规则：登录、权限等    ●开放规则：“平台”基础服务、规范、兼容等    ●制作规则：开发、调试、发布、定价等    ●容器规则：跟平台的”融合“逻辑等    ●使用规则：购买、打烊、过期等    ●管理规则：禁用、删除、推广、分账等    ●其他：安全、审核、文档等 五、举个栗子🌰 5.1、背景   笔者曾经接到过一个C端消息通知的需求，要求是服务端推送消息给C端，我们可选择的是自研和购买第三方服务，经过调研对比了：功能、性能、成本、兼容性等多个方面打算自研，那么很自然而然的想到要实现这个需求，我们可以建一个服务提供生成消息、发送消息、存储消息等等，然后实现一个客户端sdk，用于接收消息和处理消息。需求实现了，皆大欢喜了，然而我们是否就可以满足了？结项了？ 接下来让我们用今天讨论的平台化设计思维再来思考一遍。 5.2、战略思考   两步七问，规划和落地：    ●要不要功能更强大一些     ○当前的需求确实简单，一推一收即可，将来会不会有黑名单、群发、根据特定的产品范围发、是否有c端向服务端发送的消息？可以跟产品探讨一下。更多的功能是否就可以有更多的沉淀、更多的收获、跟多的发展？     ○- 要    ●要不要推广更广泛一些     ○当前是一个产品功能在用，公司或集团下有没有其他部门也有类似的需求？更多人使用我们的价值产出是否就更大，甚至将来作为isv开放给外部企业使用，未来的“钱途”是否也会更好？     ○- 要    ●要不要做成独一无二(一定范围内)     ○是否可以设计成一个统一的系统，不同的人可以划定一个“私有区域”，可以管理只跟”自己“相关的内容，比如成本、消息管理、权限管理？然后让大家都来使用，完全“垄断”某一个范围？ps：垄断的好处就不用说了吧～     ○- 要    ●可以共享使用功能和数据吗？     ○不同部门的产品同样有此类需求，达到“总成本”降低     ○可以    ●可以让更多人来自主“生产”内容吗？     ○不同的需求需要生成不同的“消息”     ○可以    ●需要统一管理用户和使用规则吗？     ○多团队使用时，需要管理不同的成本单元用户；也需要管理c端不同权限以及名单的用户和使用规则     ○需要    ●需要有更多人来一起发展吗？     ○可以开放一些插件(消息处理方向)，比如针对特定消息内容可以类型转换、展示不同交互，让不同的团队自己实现自己的“功能“，减少本团队的人力成本     ○不确定   结论：有做成平台的必要性 5.3、战术思考   根据公式： {“越来越多”} {“角色A”} {“可以“} 通过平台 {“动作”} {“很多”} {“角色B”} {“动作”} 的 {“内容X”}   思考如下：    1、定位：面向公司内部的需求，实现客户端、服务端之间的消息通信，将来可以开放给其他外部企业付费使用，简单易接入、兼容各个平台、功能完善定位于基本的消息处理并深度挖掘业务使用场景(抛弃如视频、语音等场景)、费用比竞对低、稳定安全有保障；    2、角色：不同研发、不同消息生产者、不同消息接收者、其他功能扩展开发者；    3、规则：设计一个平台，包含：运营管理系统、后台管理系统、用户端sdk/消息页等，囊括的逻辑有，用户身份相关和权限管理、消息产生发送接收流程、组织间“数据”独立和组织管理、数据(消息)的流转保存统计、成本管理等；    4、生态：即插件的设计规则，如接口定义、上传和使用规则、审核和更新流程等   最后，通过相关的“产品”设计、“UI”设计、“架构”设计、“流程”设计、“开发”设计，逐步实现整个平台。 六、最后   还是那句话，我们每个人都需要成长，从最初写一个“方法”的代码、到写一个“功能”、实现一个“模块”、跟一个”项目“、设计一个”架构“、搭建一个”平台“，这一个又一个的阶段有不同的目标也有不同的思维模式，我们要不停的改变、不停的成长、不停的思考才能应对不同的问题或者目标，一种思维模式也需要慢慢养成一种习惯。 好了，我的分享结束，希望能对大家有用，如有问题请及时与我反馈，我们一同进步～😄

在小程序开发中，1rpx边框随处可见， 像上图UI给的设计稿，如果只是简单使用[代码]border: 1rpx solid red;[代码]的话，在不同的机型上会有不同的表现 [图片] 表现IOS 机型上[图片] Android机型上[图片] 由图片可以看出， IOS机型上会有边框缺失（然而经常出现缺不能稳定复现）， 而Android机型上边框比较粗 原因上面这两种表现形式很难联系到一起 首先先看IOS边框缺失的问题，借鉴网络上前辈们的经验 当父元素的高度为奇数，容易出现上下边框缺失，同理宽度为奇数，容易出现左右边框缺失解决办法是在边框内部添加一个1rpx的元素或者伪元素， 撑开内部使父元素的宽高是偶数。 然而我们发现这种方案在Iphone 6等2倍屏可以生效， 但放在如Iphone X等3倍屏下面就很飘了， 还是经常会出现边框缺失的情况， 这种情况下再去把父元素改为2和3共同的倍数就非常不现实了。 再回过头看导致边框缺失的具体原因是啥。 在这之前需要了解下高分屏的物理像素和虚拟像素的概念 简单来说物理像素是设备的实际像素 虚拟像素是设备的坐标点， 可以简单理解为css像素 而rpx类似rem，渲染后实际转换成px之后可能存在小数，在不同的设备上多多少少会存在渲染的问题。而1rpx的问题就更加明显，因为不足1个物理像素的话，在IOS会进行四舍五入，而安卓好像统一向上取整，这也是上面两种设备表现不同的原因。 解决方法我们采用的方法是采用translate:scale(0.5)的方法对边框进行缩放 具体的代码如下 .border1rpx, .border1rpx_before{ position: relative; border-width: 0rpx !important; padding: 0.5rpx; z-index: 0; } .border1rpx::after, .border1rpx_before::before{ content: ""; border-style: inherit; border-color: inherit; border-radius: inherit; box-sizing: border-box !important; position: absolute; border-width: 2rpx !important; left: 0; top: 0; width: 200% !important; height: 200% !important; transform-origin: 0 0; transform: scale(0.5) !important; z-index: -1; } .border1rpx-full { margin: -1rpx; } 给.border1rpx的元素设置边框宽度为0给::after伪元素宽高为两倍，边框设置2rpx，边框其他样式继承元素的设置然后再缩放0.5来达到边框为1rpx的效果 用法基础用法给相应的元素添加border1rpx的class即可， （.borde1rpx说：我们不生产边框，只是边框的搬运工，要显示边框样式的话还需要在元素上自行设置） 圆角边框圆角边框需要自行设置相应伪元素::before 或 ::after的border-raduis值为预期的2倍， 如原本想要设置10rpx的圆角，需要设置[代码].xxx::after{border-raduis: 20rpx;}[代码] 边框内部填充由于设计原因，目标元素会留1rpx的padding用于显示伪元素的边框，如果内部元素是填充的，正常会看到填充元素和目标元素有小部分间隙，此时需要给填充元素添加.border1rpx_full来解决 注意点此方案默认使用::after伪元素实现边框，如果目标元素的after被占用(如iconfont)，请使用[代码].border1rpx_before[代码]如单独设置边框(如上边框), [代码]border: 1rpx solid red;border-width: 1rpx 0 0 0;[代码]不能被正确继承，请使用简写[代码]border-top: 1rpx solid red;[代码]由于设计原因，目标元素请最少设置1rpx的padding用于显示边框,(上面的样式已经有了默认的padding，不写也可以， 只是不要用padding:0覆盖)请自行测试点击功能是否正常，防止层级关系导致元素区域被伪元素覆盖

自7月7日凌晨有媒体透露，微信小程序可分享至朋友圈，此举被业界认为张小龙团队时隔3年终于对朋友圈开始“松绑”。今日（7月10日）记者获悉，智慧商业服务提供商微盟主线产品已经全线接入该功能，无需商户任何操作仅需等待版本发布后，自动完成能力接入，微盟商家便可“坐享”朋友圈社交红利。 根据微信目前开放的接口，仅安卓用户可以使用该能力。记者在安卓手机微信搜索框搜索微盟相关小程序进行测试发现，点击右上角分享按钮，即可看见“分享至朋友圈”图标；从朋友圈路径点击该分享，可看到右下角有“前往小程序”按钮，点击即可跳转进入小程序。此外，用户还可对该朋友圈分享进行二次转发分享。 [图片] 图说：小程序页面新增【分享至朋友圈】按钮，分享时可使用【分享朋友圈】常用功能 [图片] 图说：用户浏览朋友圈时，可通过【前往小程序】按钮快速访问对应的小程序页面 针对业内关注焦点“小程序分享至朋友圈是否为纯内容单页”，微盟给出了超预期答案，据了解，【小程序分享至朋友圈】能力适用范围包括店铺装修页、商品详情页、部分营销活动专题页等；此外，微盟“微客”关系链绑定能力也被接入，供微客分享分销商品与分销素材页面至朋友圈时使用。而智慧零售多网点模式下的小程序【进店规则】，同样适用于用户从朋友圈入口访问小程序。 值得一提的是，与网传需商家自行在后台手动选择立即更新并补充“店铺-微信-基础信息”不同，微盟向记者证实，微盟商家不需要繁琐的手动操作，商户在后台便可自动提交更新，微信审核通过以后即可享有小程序分享至朋友圈能力。这对拥有上千门店且“千店千策”的零售业态来说，尤为适用。 目前，微信小程序用户日活超过4亿。2019年微信公开课Pro上张小龙就坦言：从发布到现在，每天进去朋友圈的人数一直在增长，没有停下来的势头。到现在每天有 7.5 亿人进去朋友圈，平均每个人要看十几次，所以每天的总量是 100 亿次。此次打通小程序和朋友圈分享，意味着广大商家将进一步获得社交电商红利，拓宽产品展示渠道和流量来源。微盟集团高级副总裁、CTO黄骏伟也表示，微信对朋友圈的把控一直很严格，3年后小程序可以转发朋友圈，更多是考虑了微信生态的丰富和完整性。 小程序是微盟为广大商家与品牌提供智慧商业服务的重要阵地，围绕电商、零售、餐饮、酒店、外卖等不同场景和业态，微盟提供了一整套完善的行业解决方案，合作企业包括联想、GXG、梦洁家纺、林清轩、雅迪、卡宾、巴拉巴拉、珀莱雅等知名品牌。截至目前，入驻微盟商户数已突破300万。后续伴随微信对iOS版本更新，未来该能力或将有更多分享功能呈现，微盟也将为商户的接入匹配不同场景和赋能，助力商家在小程序生态中打造营销链路闭环。