@leeg810312 可能你觉得站着吃饭和跪着吃饭没什么区别，只要吃到饭就好。是不是互联网产品根本不重要，产品是服务用户的，用户体验好不好都不重要，那就没什么重要的，照你的思路以后火车上有没有位置也不重要能把你送回家就行。

@ersic 对啊 每个人都有

楼主你说的这种后台的入参在确实不确定的情况下，完全适应入参，只能采用 map 结构去接收，但是确确实实违法规范，即使使用 map 接受，你每进行一次业务变更添加或者修改一个字段（可能很频繁），后台是一点业务逻辑不需要处理么，那应该不现实，但凡有逻辑要处理用 map 和不用 map 那已经不重要了，因为无非是改一个地方还是改好多地方的问题，但是某些业务场景还是有方案去解决的，单纯的透传后端可能通过使用 map 去兼容你，但是如果大部分字段都和业务紧密相关需要做额外业务操作，那么用 map 和不用 map 没啥大区别

@Macolor21 groovy 也只不过是一种跑在 JVM 之上的语言，简化了语法，算个动态语言，但是像楼主说的这种接口字段从头到尾自适应，不是语言的问题，这是设计方面的问题

想的太简单了 如果都这样玩 工信部岂不是一点威信没有 你最起码 明面上不能被看出来 也就是前端页面数据埋点和前端请求这一层

@dqzcwxb 说你是"正义"你就是了呗，我捉摸不透现有的规则（因为 12306 对我是黑盒对你可能不是），劳烦您给我科普一下所谓现有的规则，我也好学习学习。最早显示说明是可行的，取消了说明，因为各种考量不管是铁路总局的利益还是什么。但是说明从技术角度是可以显示的。能不能回去我不知道，但是说实话我个人从用户体验度而言，最初那版的体验我个人认为更好，虽然 12306 并不会考虑我个人的体验，但是每个人都有发声的权利。

@HappyFox s 个产品经理祭天就是个玩笑话 之前搜狐还是暴风的 APP 更新出来的梗

@dqzcwxb 你就是用你那一点点所谓的知识，到处宣扬你所谓的正义，所谓的最优方案就是当前方案，别人的意见就是这不行那不行了，我除了想笑就是想笑，要是国家上面要求了显示人数，你信不信能给你改回来，估计到时候又说显示人数真香了

@dqzcwxb 规则并不一定要跟 ip 绑定 OK，我能限制平台不，我能限制每个账户只能在 12306 进行候补操作不，候补人数跟老人小孩有半毛钱关系不，你自己想不到完整的规则，哇这方案就是最好的，哇你这么干有这些问题那些问题，靠人要后续改版了，估计你又是一副嘴脸

@concernedz 候补主要不确定能不能候补到，而且也判断不出来,就挺坑的

@dqzcwxb 我说的履约是 12306，可以和各大支付平台合作，我成功购票了你划拉钱，我没成功购票我候补，你就别让我先预先付款了，对我而言你就是无法做到百分之百履约，没有道理先让我给你钱啊

@dqzcwxb 这么说吧，在程序设计上一码归一码，如果说有机器恶意候补所以不显示人数，那么应该优化的是怎么判断恶意机器，如果这玩意无法判别，所以才在业务角度出了这么个昏招。再说出去从程序设计角度真的无法判断恶意机器候补么，可以通过详细的规则+用户身份信息+平 ip 去区分把，你要是 12306 的开发，你知根知底当我没说，12306 对于咱来说都是黑盒，你咋就这么理直气壮的知根知底了呢？

@dqzcwxb 懒的怼你了

@dwlovelife 预售跟我买票还不太一样把，预售是我确定买这个东西，电商也是有履约的，我买的一定会给我，不然用户会要求进行赔付的，我预售一件有可能买不到的东西，有何道理要我先把钱给你，你到了买不了再退给我？这玩意在程序设计上完完全全可以做到一手交钱一手交票，无知导致无能狂怒这句话真是把我逗笑了，我们作为每一个真真实实存在的用户，这玩意做的好么？如果做的不好，用户不能反馈么，你的世界真昏暗啊

@dqzcwxb 不给人数就能防止软件利用数据进行恶意候补了？

最主要的问题 你删除的数据事实上在数据库里是没有完全释放的 相当于无故添加了几行隐藏数据 然后页合并和页分裂的时候 也会受影响

多问一句 要是 20 个服务器集群这种 怎么 tail

有几个人 做电商业务 有几个电商业务场景需要秒杀 需要电商业务又需要秒杀场景 然后这个活给你做 再经历过真实生产环境的考验

@sadfQED2 高峰 QPS 7000-8000 正常 10 多台服务器就能搞定的，为啥要浪费 1000 台机器的成本干这事