常用的商品上传方法有单个上传，附件上传，API上传。　　单个上传顾名思义需要将商品信息一个一个录入并上传、更新。单个上传针对所需上传商品较少的场景，是最基础的上传方式。所以不少产品MVP时期都只提供单个上传的方式，但商品量多时，单个上传的方式是比较消耗人力和时间的。　　附件上传常常是将商品信息整理到Excel，然后直接上传Excel文件去批量上传、更新商品。附件上传针对需上传的新品量多的场景，对商家来说属于人工+半自动化的上传方式。通常商家都会有自己的商品信息文件，稍作整理即可上传平台。附件上传比单个上传节省了商家的人力、提高了商家的效率，开发复杂度稍高。　　API上传可以将附件批量上传的接口加密，做成可供外部调用的API接口。对商家来说接近全自动化，几乎一次对接之后就不需要再花人力管理商品文件，更省力、高效，但是需要商家有技术团队支持。

可以设计如下文件上传的安全规则： 1.文件上传的目录设置为不可执行 2.判断文件类型 3.单独设置文件服务器的域名 4.改写文件名，文件路径不可预测第一点规则是显而易见的，是为了减小执行动态语言脚本的风险。如果被成功上传了一个webshell，但是不能执行，还是能够起到深度防御的作用。第二点，在判断文件类型的时候，我们一般要求使用白名单，而不是黑名单，因为黑名单可能会列不全，还可能会造成一些bypass的风险。第三点，单独设置文件服务器域名，也是一种针对客户端的保护。这样可能会避免许多跨域的问题。如果发生了XSS，攻击者可能还需要突破跨域的限制才能进一步扩大战果。再比如如果被上传了crossdomain.xml，可能就会导致flash的跨域问题，这些都是实实在在的风险。第四点，改写文件名，随机文件路径。这是把风险藏起来，现在基本上尽职一点的程序员都会这么设计，这也是最大程度减小风险的非常切实有效的手段。

从流程可知，我们的支付流程设计本质是对【支付触发页面】【选择支付方式】【支付成功】三个部分进行设计。如果是调用第三方支付，【支付中】流程不是我们可以干涉和设计的，直接调用就好；若产品中有”钱包支付”的选择项，就需要考虑【支付中】流程的设计；之后我们就对这三个部分进行设计分析：1.支付触发页面优质的支付触发页面，需要由支付内容+支付金额+支付入口三个部分组成：1）支付内容合理的展示内容的名称、数量、单价等信息，有助于付款用户进行内容的核对和确认，一定程度上增加用户使用体验感；2）支付金额明确的向用户展示待支付的金额，且需要清晰的展示出该金额的由来；3）支付入口也就是支付按钮。该按钮的设计集中在视觉和文案上；2.选择支付方式现存在的支付方式的选择看似很多，但是要用起来后就会发现效果最好就是那么两个，即支付宝支付、微信支付。支付宝和财付通这两大巨头占据了中国第三方移动支付交易规模市场份额的90%，其他的如云闪付、NFC支付等方式只占了一小部分。所以对于APP的支付选择来说，毫无疑问首选是这两者，将二者都集成是最好的方式。3.支付成功此环节为一个反馈环节，其设计要点是：用户支付成功后给出正确的提示反馈和跳转反馈。1）提示反馈可以采用类似“支付成功，正跳转回xxAPP”的提示语；2）跳转反馈我们可采用两种设计逻辑

1.避免重复支付肯定是要先找到源头，重复支付的主要原因是跳转到第三方支付，支付后没有及时收到支付成功的返回参数，订单一直卡在待支付状态。所以应该设置同一个订单，x秒内不能再次发起支付，大部分订单可以在这个x秒内获取到返回的支付参数。一些极个别的情况可能无法完美避免，比如极端情况x秒内还是没有返回参数，进行了二次支付。但是这样大大减少了重复支付的概率，再配和第一个问题所说，进行重复支付退款，就能完美解决题主的问题。2.重复支付最根本的原因是接口回调结果引起的，先重视这个问题。另外，避免方案，当用户发起一次支付后，是会返回结果页的，如果没有返回，当发起第二次支付时做出是否已支付的判断或做一个预警机制，多少时间内不允许重复支付。3.一般重复支付发生在用户支付成功，卡余额已扣除，系统未收到银行通知，用户再次发生支付。（1）系统未收到银行通知，可以是由于网络问题，或者其他异常调单，一般系统这里会做一个自动补单机制，就是根据订单号到银行查询该订单的状态，考虑到系统性能等情况3-5分钟查询一次就可以，查询半个小时的订单，通过这种机制可以90%的订单状态能够正常（2）订单未查询回来或者期间用户又发生支付，一般系统设计一笔订单号有一个交易状态，重复支付更新交易状态时可增加判断，如果订单已成功，系统自动发起退款交易即可4.订单支付这些接口都会做幂等处理，避免重复重复支付。成功调用下单接口后，此时会锁单，包括用户积分，优惠券...这些都会做相应的扣减。成功调用支付接口，订单状态会变成"支付中"，后台会等待银行支付结果的回调通知，当然，可能会出现后台或者银行的原因，导致没收到银行回调通知（这种情况比较少发生，银行的回调一般都会回调好几次，直到收到后台确认），所以后台还需要在某个阈值时间后，如果还没收到银行回调通知的话，定时去拉几遍支付结果，然后更新订单状态，再通知其他业务服务。

常用的支付方式有：支付宝支付、微信支付、银联、内购1、支付宝支付支付流程：（1）先与支付宝签约，获取商户id（partner）和账号id（seller）（2）下载相应的公私钥文件（加密签名使用），在客户端我们可能只需要私钥（3）下载支付宝sdk（4）生成订单信息，可以直接客户端或者自己服务端生存都可以，但是大多是服务端生存的。（5）调用支付宝客户端，有支付宝客户端跟支付宝打交道（6）支付完毕之后返回结果给客户端和服务端。2、微信支付支付流程：（1）注册微信开放平台，创建应用获取appid，appSecret，申请支付功能，申请成功之后会返回一些参数详情见图（2）下载微信支付sdk（3）客户端请求订单，后台与微信后台交互，返回给客户端支付参数；（4）调用微信客户端，由微信客户端和微信服务器打交道；（5）客户端和服务端都会收到支付结果；（前台消息不可靠，我们需要去后台验证，如果后台没有收到支付通知，后台去微信服务器验证然后将结果返回给客户端）3、银联支付流程：（1）注册申请就不是前端的事了，直接介入sdk（2）从自己的服务端获取流水号（3）然后调用银联sdk，不用跳转，银联sdk直接是内嵌的（4）支付完成之后会回调代理方法4、内购支付流程：（1）请求有效的产品代号集合（2）购买指定产品（3）验证购买（4）恢复购买

二级评论设计主要分为两种形式（具体须根据产品特性及二级评论数量决定采用何种展现方式）：其一为折叠式：以一级评论为主，展示所有二级评论，优点是一级评论及对应的二级评论可以形成清晰地对应关系，上下文联系紧密；缺点为评论展示的位置受限，假设如果二级留言内容较多，用户发表的评论需要多次点击才能展现出来。同时二级评论的点赞限制较多，如下图从百度知道评论区可以看出二级评论难以给出点赞区域。针对折叠式，一般优先露出n条二级评论，其他评论可在当前页面中无限展开或需要跳转到新的页面查看全部，如微博、百度贴吧等。如果二级评论和一级评论之间联系紧密，比如问答类产品建议采用该种方式，如果二级评论数量较多建议采用跳转到新的页面查看全部二级评论的交互方式。其二为平铺式：打破一级及二级评论的差异，将所有评论平铺开，缺点是一级评论和二级评论之间的上线文联系较弱，优点为展示位置较灵活，不必须折叠在一级评论中，如网易新闻。

用户评论可以打通用户与用户、用户与产品之间的界限，提供双向甚至多向的沟通手段，增强产品的关系留存。评论功能不再以用户发表意见为唯一目的，同时还营造出了一种隐藏在屏幕背后的社群关系。

运营操作是指运营可以从后台干涉用户的评论行为和评论结果。正向干涉包括：评论加精、评论置顶；评论加精支持运营挑选优质评论，在前端给予“精华”的标记，有的App也叫“神评论”、“有用”等……评论置顶如字面意思，将某个评论，置顶到评论列表首位，给予公示负向干涉包括：评论屏蔽、评论删除、评论人封禁、敏感词替换等；评论屏蔽将某条评论暂时对他人不可见。体验更好的做法，还可以通知发布评论人其内容被屏蔽，要求其修改后申请解除屏蔽，经审核后评论可重新出现。评论删除直接从后台将评论删除，不可恢复。评论人封禁通常是和“举报”关联，对于频繁发布垃圾评论者予以封禁，令其不可再发评论。当然也应该允许其申请解封。敏感词替换通常做法是构建敏感词库，如果评论某些文字命中词库，则将敏感词替换为“*”。被删除/屏蔽后显示逻辑当某条评论被删除，或屏蔽后，可以有两种做法，要么是直接删除，要么是当前区块保留，被删除文字变成“评论已删除”。尤其是主题式评论，由于某条一级评论可能关联多条二级评论，如果一级评论被删除，其二级评论是否需要全部删除，需要产品经理根据评论价值来决策。建议这种情况还是保留二级评论。

用户在评论功能主要操作和使用场景是评论输入：通过评论入口唤起输入框，或直接在输入框输入内容。评论输入主要的产品设计方式：1.截取式评论回复的内容连同被回复的那条内容（不管这条内容是原本的评论，还是评论的回复）生成一条新的评论，这种方式可以看做是针对盖楼式评论的两个缺点做的一种优化，2.贴吧评论（或者叫贴吧式评论）主题式评论将评论本身作为一个主题，将对该评论的所有回复，以及对回复内容的回复全部都显示在这个主题范围内，这种方式很像贴吧的展示形式，所以也叫贴吧式评论。3.盖楼式评论顾名思义就是利用评论来盖楼，每一条回复都会连同前面所有的评论和回复一起生成一条新的评论，这种评论样式的好处一是能看到所有回复的内容，整个评论看起来比较连贯，二是对于那些对评论区比较重视的应用（或者老板），使用盖楼评论时，评论区看起来会比较火爆。4.相关推荐与引导式用户在评论输入中有相关推荐，同时评论区域会有跳转广告位，方便用户在评论区跳转到指定内容。在评论输入里，除了文本、图片外，用户产生的点赞、收藏也是内容输入的形式。因此产品经理需要提前设计好这类没有语言输入的内容的默认文案，增加用户评论交互。

主流排序规则有：按热门程度、按发布时间、混合式排序。按热门程度主要是根据所有评论的点赞数量、回复数量进行排序（同时应该考虑“点踩数”、“举报数”等负面维度），通过权重进行线性求和计算。尤其是“知乎”类产品，本身是超低频工具类（不像音乐类工具型），但现在又已经存在了巨大的头部评论马太效应，建议在热门排序的同时针对一些具有时效性的内容排序，还要考虑加入时间衰减因子等等优化推荐算法。按评论时间按照发布时间正序或倒序排列，注意考虑是否提供用户选择正序、倒序排序方式的功能。值得注意的是，对主题式评论，如果一级评论采用默认倒序（为了让用户看到最新评论），一级评论下的二级评论则可以考虑采用正序来让用户更好的理解讨论进展；且需要注意的是一级评论倒序排序的情况下一级评论的倒序排序考虑是否根据其下的二级评论的最新发布时间来进行（这样能保证一级评论的排序是按评论本身的讨论进展来更新的，参考“贴吧”）。混合式排序该模式是“热门排序”和“评论排序”的综合，比较典型的是网易云音乐。网易云音乐通过设定前5条评论为“热门排序”的前5名，后面的评论按时间展示来同时提供给用户的良好评论观感和评论的参与性（用户既能感受到热评的趣味性又能有机会、有意愿参与到评论中来）。