楼主这种情况，大家的职业生涯里面肯定也难免。应付这种事情其实很简单，你就上群里面转发一下问题，一般情况肯定没人理的。这样你等个十来分钟和提问题的人说一下没人理，自己没能力或没时间解决就好了。如果人家回复了，那就认真解决一下。

长沙 10K 也不少了，有这个要求很正常。只能祝福楼主明天就遇到合适的了……

没有推广计划和方案就不要做什么 APP 了，根本没有用户，白费时间。

JWT 这种机制安全性并不高，但就是这个并不高的安全性，对一般的应用来说都已经足够了。这个世界上不存在绝对的安全，所以我们在选择安全机制的时候，要充分评估自身的安全需求。一切按需求来就行，没有必要追求更高的安全性。

@sioncheng A 失败了就没 B 的事了，A 成功了则 B 必须成功。至于 B 在多长时间内成功，肯定是越短越好，但如果这个时间比较长，那也必须接受。反之亦然。

首先要明确一点：一般业务系统是不可能通过实现分布式事务来保证一致性的。

业务系统不同于数据库，因为对于数据库来说，所有的数据都是抽象的，对于数据的操作也就是 select insert update delete4 个命令。而业务对于业务系统来说是具体的，对业务的操作也并不能抽象为增删改查 4 个接口。所以在业务层面实现 2pc 、3pc 事务是天方夜谭，根本不具备可操作性。

我天天用，都不知道 iPhone 有什么问题……

我相信楼主说的那么多问题可能是真有那么多。但这些问题对于我来说是不存在的，所以这些问题完全不会困扰我。我相信那么多 iPhone 的用户中，绝大多数是和我一个情况。

不要想太多。在古代或国外，社会底层要完成阶级跃升，一般都要靠几代人的共同努力。现在国内一代人就能完成，已经很快很快了，不要不知足。

请参考： https://github.com/xuanbg/gateway 里面的实现

SE 已入手，对比 6S，真香。当然和 11 是不能比的。

续航还好吧，1 天 1 充的节奏。

@Rxianbei 除了少数会造轮子的程序员和你这样的会用轮子的程序员外，更多的其实是第三种：除非有人告诉他，否则就不知道用什么轮子的程序员……

发期刊难道不是走导师的路子才是正确的打开方式么？楼主你居然连征求导师的意见都没有就去发……

正规的做法是 2 楼的方案。当然 1 楼的也能用，但不推荐。

返回使用不同的 dto 即可，不同类型的转换可以用 A 对象序列化后再反序列化为 B 来转，不需要一个个 get/set

是的，做前端无论你用传统的 jQuery 还是流行的 VUE 什么的，MVVM 模式都是要搞起来的。一旦开发模板磨合出来了，开发新页面简直就是流水线生产一样高效。

事实上我连古老的 Winform 都搞起了 MVVM 模式。控件拖拖完成一个 View，里面坚决不写一行代码。然后搞一个 ViewModel 类，构造方法里面专门写数据双向绑定的代码，和界面交互的事件绑定，一般都是几个方法实现一下事件触发后的交互逻辑，百十来行代码就搞定。然后再来个 Model 类，就负责构造 ViewModel 和转发数据，通常也就几十行代码完事。

这样分割后最大的好处是代码结构通用化和模板化，一些公共的处理逻辑就可以提取出来，搞几个基类，让业务类去继承一下，就可以少写很多很多的代码。

@FanError 对的，确实性能不好，但我们的业务每天新增的数据都是以百千计而非百万千万计……所以我就不管他性能好不好了，只要用的方便就好。真香

这不是 hash 算法大干快上的时候么？客户端算一个哈希上传，服务端也算一个哈希出来比对就行了呀。只是需要注意双方计算哈希的时候，对象序列化后属性的顺序可能不一致的问题。

@JaguarJack A 和 B 之外搞个 Common 就行，AB 都依赖 C

@abcbuzhiming 功能边界肯定要划分清楚的呀。

我在带团队的过程中一直强调，把代码写对地方比写对代码更重要。代码写错了很快就能发现并修复问题，写错了地方则不然，当时是没问题你好我好大家好，但会让你在后面一直吃屎。。。同时也会在合并分支时产生大量的冲突。

事实上只要在写代码之前稍微思考一下再动手，就很容易解决功能边界的问题，也就能把代码写对地方了。