贴到 ip138 去看看咯

你慌什么，像你那个树形结构，要根据 ID 调别的接口的，如果要你循环调 N 次的话，你调呗，他服务支撑不住让他们头疼去

@coderluan 想到这个我都想笑，人社部在呼吁企业招聘不要有年龄歧视，结构国企每年的招聘清单，还是清一色限制 30 、35 ，哈哈

@CodeCodeStudy 那就不知道为啥你被针对了，大家都看得到，而且这个图床，V2 最多人用的了

可以增加安全性，浏览器报不安全，是因为浏览器不认识你这位自签机构，或者说不承认你。
但是你自己知道自己是个“好人”，所以你们内部人员自己用，没有问题的，也是拥有了 ssl 保护

@wudicgi 嗯，所以上面代码应该就是使用的 PKCS7 了，因为是动态填充的，那 java 示例应该是有问题的，除非像楼上有个同学说的，java 这样写是历史遗留问题

@Great233 按我找到的相关 AES 资料，我的认知也是 PKCS#5 填充不能在 AES 加密的 CBC 模式使用，因为 AES 的 CBC 模式，最短的块长度是 16 ，而 PKCS#5 适用于块长度为 8 。关于 java 方面等问题，我就不是很清楚了，毕竟不是做 java 开发

@CodeCodeStudy 不可能吧，你都能翻到这个网站，imgur.com 上的图片应该看得到呀

@yuzo555 行是行，不过别人的扩展包，兼容性处理做的比较好，面向对象风格也比较好写

@nothingistrue 那这样的话，就意味着从公司制度改革的时候就要进行正面对抗了，做好离开的打算。而不是默默接受制度改革，后面被裁变得被动

@0914xc 没用 4 ，我用的还是 gpt-3.5-turbo 这个模型

和你讲实在话，你工龄太短了，你也没提加班时长、休假剩余，我就假设你没有这些存余吧。
说对公司最坏情况，无论是 n+1 还是 2n 都是赔 2 个月，所以你换位思考，作为公司，协商情况下为什么要给你赔 2 个月呢？大不了你去告，拖一拖恶心你。
所以我个人建议你，心里底线要 1 个月，往 1.5 个月争取，要方案 1 好，不要什么 80%这样的垃圾方案，有年假未休什么的附带和 HR 提出来，要求算钱，不行就休掉，提前走或拿来面试。
最后走前不要有负担，照常就行，项目做不完关你毛事，没必要加班。

@xmumiffy 你们设置了多少次的重试机制，目前我没有在服务端设置自动重试机制，我担心重试的话导致响应时长过长，大量连接拥堵在这个接口

请教大家个问题，如果面对像楼主一样的情况，中途公司出制度，改革拆分工资结构，把原先的固定工资拆分了固定+绩效+其他，请问如何对抗，可以拒绝吗？这个制度是针对整个公司的，如果大部分人同意，少部分人不同意，可以的吗

@rockyliang 订阅型的

自己开发没试过，但是用过这样的产品，美橙互联的，他们有个建站系统，就是有个 PC 网页管理后台，拖拽组件排版，有网页、小程序

有些是转接，那些公司要省钱和效率，笑死，本来大家都烦骚扰电话，还不考虑用户体验，我是听到嘟或者前面机器人播报，我就直接挂了，你慢慢转吧，拜拜了您嘞

@SingeeKing 好的，感谢解答

@MozzieW 我们流程是完善可用的了，客户端的我不管。我目前只是说我在服务端保存了客户端提交的所有 receipt-data ，然后用 receipt-data 去 https://buy.itunes.apple.com/verifyReceipt 接口拉取数据做分析，如上所说，我观察发现某些不同的 receipt-data 拉取的数据是一样的，可能是同用户恢复购买吧，只是 receipt-data 不同而已，我想删除一些这种重复的 receipt-data