主要目的防止秒杀地址提前被“刷客”知道，防止使用脚本自动刷。只有秒杀开启时才能知道具体的秒杀地址，让这样大家处于同一起跑线上。

个人见解：

1. 若没暴露秒杀接口，像我们程序员可以提前捕捉到执行秒杀的具体url，

   1）根据里面的信息推测出其他商品的秒杀地址；

   2）建立不同的用户对应的秒杀商品的url；

   3）虽然现在无法秒杀（秒杀时间未到，如果时间未到，后台却接到了某个秒杀请求，嘿嘿嘿，这个用户需要封锁，他想搞事情！！！），但是时间一到通过循环发送请求，占用服务器端大量的请求，相对其他用户就不公平了。

2. 秒杀接口只有在秒杀开启的时候才暴露，有人说，那我照样使用这个秒杀地址执行一系列的循环脚本访问，不也一样嘛？首先我们程序员需要知道第二次访问就是秒杀商品的对应的url，万一不是呢，第二次访问可能只是用户信息的提交，第三次才是呢？因此我们这边需要在众多url请求中筛选出最终的秒杀商品的url，所以在提前不知道目标系统其秒杀的逻辑和顺序的话，应该需要花一段时间进行分析。。。然后等你分析完了，发现秒杀已经开始5分钟了，普通用户已经抢完了。。。

我认为，老师这样做还是有一定的道理

在秒杀前，你不知道秒杀地址，是没被刷的，当你点击秒杀开始时，你的手机号会被验证，然后进行md5对比，秒杀成功，秒杀地址暴露，嘿嘿，数据库已经有你的秒杀的记录，所有你再去刷已经没用了

还是加个人机验证靠谱。

这不是然并卵嘛。。

1- 我写个脚本等着你暴露秒杀接口，用脚本拿秒杀地址然后秒杀

和

2- 直接写个脚本秒杀。。

区别大吗？

秒杀这一业务：首先需要查询商品的秒杀状态查询和然后执行秒杀（减库存+下单）。如果将这两步合在一起执行，就会让刷单人员，提前知道执行秒杀的地址（URL）是什么。你说危不危险

所以老师将这两步进行分离，只有在秒杀开始的时候才放出执行秒杀的URl

我想了下 可能原因： 1、暴露秒杀 和 执行秒杀 是两个不同业务，互不影响  2、暴露秒杀 的逻辑可能会有更多变化，现在是时间上达到要求才能暴露，说不定下次加个别的条件才能暴露，基于业务耦合度考虑，分开比较好。3、重新更改暴露秒杀接口业务时，不会去影响执行秒杀接口，对于测试都是有好处的。。。

另外 不好的地方是前端需要调用两个接口才能执行秒杀。

同感，秒杀地址要暴露，就牵扯到了秒杀对象的缓存。这里为什么要暴露。没搞明白。

代码规范，看过一片手记，讲经理写接口，下属写实现类