实际业务场景及问题场景1、在订单列表、订单详情中，不同状态（待付款/待发货/出库中/待收货/已完成）的订单，展示的操作按钮不同，而且列表中按钮展示的是一种形式，点击进去在该订单的详情中，展示的按钮又是另外一种形式； 场景2、商品详情、某些活动页面（其中涉及到了商品），或者是APP内嵌的H5页面，不同端/不同身份，展示的价格不同，价格文案也不同； 处理方法与思路 简单说明：2个场景不论怎么说，非常

场景及问题 场景：就是很简单的商城下单付款流程，付款时可以分享给微信好友，好友打开链接可以进行代付； 问题：这个功能已经上线正常运行了很久，但是这几天，突然从客服部门反馈回来很多异常案例，很多用户分享出去想让好友代付，好友打开代付链接时，显示的不是代付的页面，而变成了分享人要分享的页面，多见于安卓系统；详见下图，打开代付链接，看到的应该是图2，而不是图1中的发起代付页面； 解决方案及思路

前言 第2部分，主要介绍利用Hexo框架写博客，以及配置一键发布 安装Hexo以及推荐的插件详细的安装步骤及教程我不会发，因为真的不复杂且繁琐，第2部分的文章不同于第1部分，可能一个前端开发比较擅长写代码，但并没有接触过服务器，所以我会非常详细的讲解。第2部分其实就是一个大纲，如果你看着大纲都无法搞定，而且自己无法解决，你可能真的不适合写代码，更不要说搭建一个博客了，不懂就百度，不懂就问，这一点

前言 由于之前的云服务器没有及时续费，导致服务器数据被清空，虽然有备份，但之前博客使用的是wordPress搭建，再搭建一遍觉得特别麻烦，而且还要部署服务器，安装各种环境，博客应该是为人服务的，能够实现最基本的文章管理发布、数据自有，就完全足够了。 目前的解决方案、成本、从0开始所需的时间解决方案：对象存储空间 + Hexo博客框架 成本： 几乎为0 域名的费用（如果想要个性化就自己买一个想

业务说明及遇到的问题 数据埋点、上报在电商业务中非常常见，前端也经常做，实际场景无非就是：记录商品浏览量、记录下单付款行为、记录取消订单行为等… 在我们公司的实际业务中，涉及到的如下图：可以看到是以商品ID为主对象，进行一系列记录；看似没有任何难点，只要有对应的行为，那么请求接口上报即可，但这种常规的做法此时出现了极大的问题； 遇到的问题：因为平台的用户量太大了，光是注册用户，就达到了1000

实际业务中的问题在实际的业务场景中，经常会出现关闭按钮、领取按钮等，但有时UI设计的很小，用户在实际使用时存在点不到，不好点的问题；部分UI如下图： 使用css解决定义一个css类，需要用到的地方直接把这个类添加即可使用；如果觉得20px太大就改为10px； 123456789101112.expand--click{ position: relative;}.expand-

业务说明类似于首页菜单的这种布局，服务端给出菜单列表，前端使用使用flex进行排列布局; 要求：1、从左往右依次排列2、主轴上的对齐方式使用 space-between 难点难点就在于要求的第2点，每一个菜单盒子，根据UI图，是固定的宽度，在布局时，希望使用space-between自动均分，所有的菜单盒子左右位置都不使用margin，从而达到所谓的完美均分 直接写一个DEMO示意吧：假设有9个菜

实际业务场景在电商的实际业务中，比如提现、提交一些评价，还有很多场景的按钮点击，都需要做一下按钮的点击限制，假如说用户疯狂点击提交按钮且服务端没有做任何限制，数据请求就会重复，可能同样的评价重复提交了好几次；这里就以提交商品评价和提现为例： 节流和防抖的区别节流：throttle节流一般用在按钮点击、提交的时候，用户可能用疯狂点击这个按钮，假设我们可以限制，在5秒钟内无论点击多快多少次，只有第1次

为什么非要手写之前写的一篇文章，比较两个数组内容是否一致，其中就用到了every和some方法，都是ES6数组的迭代方法； 虽然现成的方法用起来爽，但是内部的原理到底是什么，看似简单的方法究竟是如何实现的？ 所以如果能自己写一下，好处有：1、彻彻底底弄明白实现原理和思路2、巩固自己的原生JS基础3、给别人装逼，显得自己很专业 自己实现every先看ES6中的every用法，遍历列表，每一项都符合条