@wanlei1766 你已经入职了吗？

纯粹想太多了。 应届生的话 正规公司都会比较宽容的，好点的甚至有比较完善的培养体系，说白了，前面三个月甚至半年都不指望你能有多少产出。所以单纯工作上的问题走一步算一步，抱着谦卑的心努力学就可以了，校招可以进大厂的人 多半不差的，对自己有点信心。

另外氛围不好或者 pua ，这个说实话就是看你运气了。 慢慢经历吧，成老油条就不怕这些了

想请教一下，币圈的盈利来源是什么样的呢？
加密货币在国内好像有点尴尬

这东西根本没一个标准，还是主要取决于 公司招人急不急 /候选人多不多。

不急又有得挑的时候，别说有空窗期了，待在一家公司时间稍微短点都不要。一本看不上，985/211 起步。

@mooyo 深圳果然有点离谱，这价格广州起码能租个两房了

没做过外包，但是带过外包。外加我其他一些了解，仅供参考。

外包的工作楼上说明的挺好的了，你虽然在对应的大企业办公，但是你并不是该公司的员工，该公司的一切福利基本与你无缘。 之前在腾讯的时候，外包连门禁权限都没有，出入办公区还得等正式员工帮忙刷卡开门。

这些都还不算特别离谱，重点是工作内容，属于是有任务了就叫几个外包过来， 做最脏最累的活。 印象深刻的是有次技术讨论的时候，大家说这个方案可以，但是某部分的工作比较麻烦，属于重复打螺丝的类型。 另外一个项目负责人就说：这个不算问题，交给外包就行了。

所以外包是和核心项目技术无缘的，你想从外包的经历里好好沉淀学习非常难。

而且态度上，大厂的员工也大概率没有把你当同事，是把你当工具用，所以技术讨论不会叫上你，也不会跟你有过多的解释，再加上从事的都是技术脏活累活，成长性非常堪忧，久而久之我觉得也会失去思考的能力。

基于上述的事实，稍微上点档次的公司招聘正式员工时，外包经历都是非常大的黑点，因为默认外包经历没有技术含量可言，简历这一关都非常难过。

我的想法：
1. 车的各项开销对你来说较为轻松。（考虑一段时间失业、不工作、奖金等不稳定收入大幅缩水等情况下）
2. 确实能给生活质量有较大提升（经常出去周边郊区游玩、经常出行且行李多例如有小孩的情况、充面子等等）

两条起码得占一条

你细想一下，如果你想精确展示 总页数，这个 count 值是肯定需要的对吧？ 查询是避免不了的。

如果你觉得每次查询有点浪费，那缓存的作用就是减少 DB 查询压力的，所以上缓存就好了，至于前端缓存还是后端缓存看你的业务；
缓存更新机制则看数据实时性要求，要求比较低可以设置个几分钟自动过期都行。

但如其他楼提到的，相比于 count ，翻页到很后面的时候 limit offset 的问题一般更大一点，DB 要抛掉非常多的数据才能取到当前页。

所以现在蛮多地方都直接不显示总页数，而是”前一页 /后一页“的方式，因为很少有人真的翻到非常后面的页数，不必要花大力气支持这个伪需求。

打当地市长热线咨询一下。

广州地区的我咨询过，可以是可以，但是额度少非常多。还是得自己交

也有过这样的时期，细想一下如果是无来由的，那可能就是大姨夫日来了，这个是有科学研究发现确实存在的。这种时候去运动一下，跑个步会缓解。

如果潜意识里是担忧事业、或者其他人生问题，其实这种时候我个人感觉是最适合读书吸收的时候。

你带着困惑去读书，效果是最好的，当年就是在职业瓶颈期读了 《少有人走的路》，收获很大。
讲实话我之前完全看不进这种类型的书，但是也是因为对事业，人生迷茫，越看越上头。

当然这本书也不一定就适合你，不过现在找书太容易了，带着你的疑问和困惑，去找本书看看

那不如 1w 搞一台 m1 的 mac pro ？ 标配就是 16 + 512 的，比你 mini 多个屏幕岂不美哉

我理解的，架构师其实说白了和普通开发没有特别明显的界限区别，很多架构师平时可能也在写业务代码。
架构师的活，很多开发平时也在做，就是写技术方案，优化已有架构、设计新的系统架构。

要说区别的话，就是比普通的开发经验更多，对于技术方案和软件架构更有心得。

要成为架构师的话，我分享一些我的思考：
1. 要有经验和技术广度打底。
经验帮你了解 实用套路，技术广度则是熟悉常见的技术方案、组件，了解他们各自的优缺点、适用的场景（这点很重要）。
2. 技术之外的阅历经验累积。
很多时候设计一套架构不能简单完全从技术出发，你得开始考虑一些其他的东西，比如：
你得考虑这套技术方案的上手难度，维护团队水平咋样，搞不搞得定这套方案；
这套东西的成本会不会太高了，是不是换成本低点的方案，会让架构复杂一点，麻烦一点。
某个中间件虽然很适合现有的架构，但是社区不活跃，维护力度也差，如果出现 bug 比较难处理，是否退而求其次换个社区活跃点的。

3. 形成架构设计、评估套路
比如怎么评估现有的架构是否合理？让你从 0 开始新建一套系统的架构，你的思路是什么？这方面可以从别人分享的一些架构文章学习一点，但最重要的还是 结合自己多年的经验，总结出自己的一套思路，才能在日常工作中运用自如。

4. 牢记一些规则
没有一套架构可以打遍天下。阿里、京东、pdd 虽然都是电商，架构肯定是不一样的。
先有场景，才有架构。抛开具体的业务场景聊架构只能泛泛而谈。
要考虑业务发展，但不要过渡设计，合适的架构都是慢慢演化而来的。比如一开始业务还不知道有多少量的时候就上分库分表，异地多活多中心等复杂的方案， 会让初期项目落地的成本和时间压力变大。
清楚地知道自己架构为了什么场景设计的，在什么场景下会有问题，并清楚地向相关人员重点说明。（比如系统不适用于高并发，或者不适用于响应时间非常敏感的场景）
...

确实很贵，而且后期估计还有销售不停地让你们加精修照片张数，报价能好几百一张，你说不要了还会反复地磨你加照片，翻来覆去地说哪张好看还是加一下。

男生一般还比较理性克制，但女生感性可能架不住 一辈子就这一次之类的话语反复洗脑。

我结婚照好像也是三四千订的，拍了五套服装，最后选片的时候销售来回磨，老婆又加了大几千。但确实就这一回，你太小气又和老婆闹矛盾也操蛋。

真的，国内现在很多行业就是逮着结婚生娃使劲薅，觉得这是刚需你们舍得掏钱。

其实现在年轻人想开了挺好的，除了吃喝玩，结婚生子算啥刚需？

52

能说下具体哪个业务线吗？

字节面试八股文太多了。。

外地社保怎么交？

接受其他语言转 GO 吗

听起来感觉像是数据库锁竞争，没 SQL 也没啥思路。同一个用户的话做点击频率控制下

看你描述操作的内容不少，追求前端响应体验的话，可以把点击操作成功，改成点击提交成功。
接口只提交操作任务，后台慢慢执行，这个要看业务上能不能接受