@Hoozy #91 啊哟，这么牛 b ？

拍着胸脯说自己五险是足额缴纳的？
签工作发 JD 的时候说 10-17，签合同写市最低工资，不是骗？
帖子里写“没事的时候不加班”，结果到了公司就没有“没事的时候”，不是骗？自己公司里的员工天天是怎么加班的，敢在 V 站发个统计记录的帖子吗？敢说明白到底基本工资给了多少吗？

先不说现在还有哪些正常人开的公司不给公积金，劳动法规定每月加班时间不能超过 36 小时，加班工资不能低于 150%，双休日双倍，节假日三倍，这些做不到都是违法懂不懂？

片面？就看你这嘴脸这公司用不着片面

@Hoozy #74 妈呀，求求你别说话了，你这简直就是在给 LZ 提供现场证明啊

加引号的是你自己说的话：

“合同问题已纠正，这个问题如果只是我们一家，请欢迎继续打脸”
已经纠正没纠正不知道，反正之前合同是有问题的，对吧？别家公司这样，那你们这些公司都是 shit

“五险一金没有，一金没有，我们确实承认”
五险一金是国家规定的，少一个都是违法，这么大方承认的你还混不混了？啥不知道五险一金里面就养老保险和公积金给的多，而且公积金还能取出，是实打实的钱，不给公积金，五险也不知道是不是按全额缴纳的，光荣得很？还有脸说？

“初创公司人员流动不是很正常？如果真如你所说这么频繁，为什么早期来的人不走，正如你所说，大家是老实人？ 老实人好欺负，这世界还有人是傻子？”
傻子都留下来了，或者留下来的是既得利益者，这不能证明什么

“你扛不住压力 你为什么要呆。别人扛得住 为什么你扛不住？”
我给你一个耳光，你先反省一下你自己，为什么我就打你，不打别人？非洲还有人一天只能吃一顿饭呢，你凭什么不能，非得一日三餐？你给员工股份了吗？都是打工，给的也不多，也没期权股份，有什么脸让人扛得住压力？给得起华为的工资再说压力好吗？

“你到一家找工作，自己会不带脑子，这样的公司，你觉得你会来”
嗯，说得好，骗子都是对的，被骗是活该，你们这些受害者死一死好吗？

“作为一个初创公司，以主贴这样的骚操作，你们觉得能留住谁？留不住人，公司还开什么开，关门种地得了”
你自己都承认了，“初创公司人员流动不是很正常？”真要是独角兽，大家巴不得三五年纳斯达克敲钟呢，用得着走？确实留不住人啊，不然哪来的“人员流动很正常”？

就你这嘴脸，放弃 V 站吧，这个牌子要臭了

@Weny #9 MBP 没有 AC+，只有 AC，了解一下

@qiaoyang #2 No offense, but why are you so jiaoqing

估摸着不是在核电站钻管道，就是在哪个变电所爬电线杆

已经提前给题目的话没毛病，这都开卷了，程序员解决不了基础技术问题？

面试怎么问有意义的问题？问了你们又要说，‘拿业务问题在面试的时候找解决办法，low ’

首先，rpc 使用 http 调用一点毛病也没有，rpc 本事并没有规定一定使用哪种通信协议实现，只是在一般情况下，我们选择使用 rpc 会有一定的性能上的考虑，那么这时候就会偏向于使用更高效的传输方式，比如使用 TCP 传输序列化后的二进制数据，而不是使用 http 传输字节码；
其次，grpc 确实使用了 http2，golang 的 rpc 标准包里也有通过 http 实现通信的方法，但实质上，它们都只是借用了 http 来建立连接，当连接建立后，里面传输的都是序列化后的二进制，而转换数据到二进制的过程，是在 stub 函数中进行的；
然后回到 rpc 的定义来看，其实 rpc 要解决的问题，就是怎么样可以像调用本地同进程的函数一样，调用一个 remote server ？ rpc 给出的解决方案就是使用桩函数来屏蔽 remote 调用，在 client 本地直接调用桩函数；
那么楼主的问题到这里就可以解决了：当然可以使用 ajax 来调用 rpc server，但需要生成 ajax （也就是 javascript ）可以直接使用的 stub function，在这个 function 里进行 remote 交互，至于是否在这里进行序列化，讲道理是应该的，这样能提高传输效率，但如果不做也没问题。只不过，要是这样的话，为何不直接使用 restul ？相比 rpc 调用，restful 不仅更容易调试，也容易进行权限和参数的控制，同时更加灵活。

你有他的联系方式，他也有你的啊，你怎么治他，他就怎么治你，所以喵喵喵？

@liyunbo #11 妈呀哥们，你这是在哪啊？工资咋还能越来越低呢？

运康锅巴，牛肉味的不错，以前有种番茄和香辣味的也不错，最近在超市很少见了

加拿大的看不看？最近在看空中浩劫

qq 是你们年轻人用的了（捂脸
简历丢我邮箱可好？我们既要 python 也要前端，坐标北京国贸
email：aGFuc2hhb3dlbkB6YWloLmNvbQo=

@tulongtou #10 哪发布了？ 8750 虽然有了偷跑的数据，但还没正式发布好吧，来个官宣新闻链接？

@lalala121 #18 来源请求？

@nl101531 #12 可以，是一种解决的思路，但我倾向于不使用这种方法，至少不作为设计阶段的方案使用，很大程度上 token 的作用就是为了在请求量比较大且多终端复用的情况下，减少登录和用户数据查询操作产生的数据库压力，如果每次还需要检查 token 版本，不如直接用最基本的 session 来实现；修改密码需要多终端下线的操作，可以通过向终端发送重新登录的通知来实现，如果担心之前的 token 没作废产生的安全风险，应该把在敏感场景中排除 token 的效力。比如，正常的查询操作都可以使用 token，是不会触发重新登录的操作的，但如果涉及到财产、敏感信息的查询和操作，都应该进行重新登录并用 session 维护登录信息。token 永远不是安全性高的解决方案。token 也不是为了这种场景存在的。


@bayker #15 我上面举的例子应该能回答这个问题：token 用于频繁且不敏感的操作。