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

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