国内大部分短信服务商直接不支持短网址动态短信，因为无法审核，就非常的无语。

先去学美术和设计配色，否则纯粹从技术上来说学了用处也不大。可能必须要学的只有布局，盒子模型，定位。其它动画，缓冲这些用到的时候再看看就好了。你都说要你要做全栈，注定不可能抠细节，否则 CSS 一门就会耗费你非常多精力，这个玩意要搞透彻也是很花费时间的。如果学 Style Object Model ，就更花费时间了。

和你同龄

玩乐器，打游戏，打球，跑步，爬山，学习充电，补充睡眠。马上快 30 了，天天感觉时间不够用，你竟然很闲，羡慕...
还能玩 2-3 年，结婚了就没时间耍了，准备为别人活着喽。

看你使用的软件，最好提前查询一下你当前机器运行的所有软件是否已经对 Ubuntu 2204 做了兼容测试，发布了兼容的版本，否则不建议你升级。我升级的时候遇到过问题，后来失败了，不得不降级，浪费了一个工作日的时间。

@chaleaochexist
1：protocol buffers 和任何基于文本的序列化性能差异是很大的，它是一个规范，只要最终大家都支持，那它就会成为 HTTP 那样的共识协议，这个共识在二进制序列化上要达成只要 google 这种全球化的公司才有可能完成。
2：HTTP 2 通过新的链接复用，在传输上已经解决了低效问题，然后就是对基于文本头的魔值定义再次压缩的通讯的协议头大小，基本上在传输上效率大大提高了，但它的核心问题还是 body 部分需要一个统一的二进制规范。
3. 最核心的是 HTTP 协议有很多功能是为服务器-浏览器模式定制的，这些功能在服务器-服务器的时候没啥作用，这部分功能在 gRPC 通讯层可以和直接屏蔽掉，不对最终消费 gRPC 的用户开放。

HTTP 比 RPC(这里特指 GRPC) 开发更快速高效简单? 这个观念不知道你怎么有的，HTTP 现在一点也不简单。
HTTP 创建之初就是为纯文本通讯而设计的,它天然的通讯协议开销是无法通过技术手段消除的，HTTP2/HTTP3 都无法解决这个问题，虽然它们做了很多优化和压缩。
gRPC 这个设计最初就是为服务之间的相互通讯设计的，它一开始就采用了和语言无关的二进制通讯模式，这使得它天然更加适合服务通讯，HTTP 协议提供的很多功能在服务相互调用时根本不需要。

尽量避免啃老，我的想法是这样的，父母有钱另说。我的首套房父母出了 50 多万，我的打算是将那套房子还完房贷后赠与给他们。他们送我读完大学已经非常不容易了，没有必要花光他们一辈子的积蓄来为自己图安心。今年我应该就能将首套房子贷款还完，然后过户给父母，然后准备存钱买自己名下首套房子，重庆房价还好不离谱，我自己努力肯定能在市中心在搞一套。我买首套的时候，问过我妈，如果她想要住，我就买，否则我肯定不会花他们的养老本，他们一辈子都在吃苦，存钱，一辈子过的太幸苦了。

核心课程: 1-3 本教材， 然后扩展这些核心课程, 这些核心课程都有对应的优秀教材，并存在大量的扩展性阅读资料：
计算机概述(文化， 入门课程)
计算机组成原理(数字逻辑电路可选)
操作系统
数据结构与算法(这 2 个东西前期不需要分家)
编译原理(可选)
数据库系统(至少熟练使用不同类型数据中常用的 1 种)

学习至少三类编程语言：面向过程， 面向对象， 函数式， 如果前面三门没有 JavaScript ， 最好还是要加上它。
最后选择一个自己最感兴趣的开发平台(Platform)。这部分需要深入挖掘，大学毕业时候能出活，毕业后能靠其生存。

然后是学习软件设计，这个路非常漫长，需要实践，从面向过程开始，到深入理解面向对象，函数式编程，项目管理，需求分析，分布式系统设计，云原生等，路漫漫，也不需要着急。

学好数学，特别是离线数学 /线代 /高数，它们都可以让你走的更远。学好英语对掌握第一手的学习资料有非常大的帮助。

最后是兴趣扩展，这个就看你感兴趣的方向了，如果你打算读研，那学习的思路可能就需要调整。
最后的建议： 不要在那些非核心的赶时髦的课程上花费太多时间，因为大学的精力和时间都是有限的，你必须选择舍弃掉那些在大学本科你不可能深入研究的课题。

要做高可用性,只能搞 iOS 支持 FaceID 的版本,这种软件已经有成熟的了. 这种留存率极低的,估计很难存活.

@kwh 并不是说不行，而是开发会遇到很多问题，这个问题很复杂，不是几句话就能解释清楚的，微服务提供了 X/Y/Z 三个轴方向的伸缩性，具体的还是要去看书，因为这个东西本来就非常复杂，单体应用因为耦合度太高，不管是测试，部署，开发，都会有诸多问题，但微服务解决了单体的一些问题，它按照功能任务分解了大型系统，并使得每个系统能够独立开发，测试，运行。只是需要特别小心，不要搞出分布式单体应用程序。同时也引入了分布式固有的复杂性，因此没有谁好谁坏，要看你项目的性质，团队结构等等，微服务架构很多时候还需要基础设施的支撑(因为微服务使得部署的依赖问题变得复杂化了），如果单体没遇到什么问题，继续用单体也不是不行。

@ggp1ot2 tar 和 gz 是可以混合在一起的嘛，完成打包和压缩工作。

看是否需要保留文件在文件系统上那堆附加标记，如果纯粹只需要保存文件内容和文件夹结构，选择一个压缩率搞得的就行，我长期需要在 Win/Mac/Linux 交换文件，zip 文件在资源管理器可以不解压查看，所以 ZIP 还是用的最多。

@samohyes 你将浏览器发送的 GET 请求的网站 URL(带有查询参数的），作为 GET 的第一个参数，不要 params

@samohyes 请求失败了，正常应该返回 application/json, 你现在返回了 text/html(就是错误页面）。

HTTPS 抓包办法网上搜一下，很容易搞定。

一看就是你少发送了请求参数，这个服务器后端估计用的是 nodeJS,然后它们将服务器错误返回给你前端(这是大忌）。把代码贴出来。另外你为了确定发送的请求是否一样，可以直接抓包嘛，对比一下两次请求的 HTTP 请求消息，一下就知道发送报文的差别了。

我感觉可以看看这本入门的书籍，你大概就了解微服务到底是个啥了，其实这个玩意没有什么准确的定义，大致上大家有一些基本共识了，因为毕竟还在发展，没有完全成熟。https://book.douban.com/subject/33425123/
它主要还是为了应对单体架构的局限性搞出来的。

@fiendo 就是每次都想踩点到一个完美时间，完成所有流程后，坐上车，车就走，我这么玩过好多次，专门卡火车的发车时间，但有一次在深圳北站排队太久，结果 gg 了，后面就随声携带一本书来缓解在车站等待的焦虑。