颈椎变直很多人都有 好吧。保证睡眠充足，锻炼身体，用眼不要过度。另外也要关注血压情况。
楼上说得对，对症下药。先找找原因

mark 一个。拖延症患者晚点来回帖

兄弟们 又到晒博客的时间啦
https://foamzou.com

刚看了下楼主的文章，内容挺好的，已订阅。
不过没搞懂 newletter 是一种什么，拿竹白来说，像是一个 支持订阅的、不搞个性化推荐功能的博客平台？
至于楼主提到的 输入 -> 加工 -> 输出，没太看明白，是否指的是不需要有太大压力写文章？写出个草稿，发出来，以后再修改也 ok 。那么这种方式普通博客也能做到，因为这只是取决于作者的心态和想法。
因为没有注册竹白，不太了解怎么个 flow 。 若有偏差，见谅

@919615766 #16 这是一个平台 兄弟

基本要求：学历和学校一本及以上
不愧是国企

学前端慢慢来可以找到工作和渐进。后端，我担心他连工作都找不到。

@wzcloud #1 兄弟 你这错字真是伤害极大啊。 一个 -> 一共。

不知道楼主说的项目文档具体是哪种呢？
API 文档，能够描述清楚请求响应的参数即可；楼主说的可能是 系统设计、业务逻辑文档。

写这类专业性文档，有几点要注意的：
1. 描述清楚上下文。需要用些篇幅来介绍背景、上下文，专业术语。写的时候要代入读者，设身处地思考 TA 能不能看懂。
2. 逻辑清晰。最好列个大纲，不要想到哪写到哪。多用 1 ，2 ，3 描述步骤或者阐述观点。
3. 图文并茂。文字难以描述的，务必带上图。

有兴趣可以看看我的博客。https://foamzou.com 。
若楼主有博客也可以贴出来，我们一起学习交流。

electron 跨平台，有 web 开发基础的话，上手很快，开发效率也高。
原生 swiftUI ，会流畅那么一些，颜色和 UI 适配方案做得不错。遇到问题的话，解决方案没有 OC 那么多。但 swift 写起来比 OC 舒服。
原生 OC ，毕竟这么多年了，该有的方案都有。但 OC 语法很别扭。

祝大家还有我，我的家人朋友，新的一年身体健康，万事顺意。

第二排第三个。谢谢楼主，祝你和女票长长久久。
[email protected]

我安卓，tasker + webhook

ifconfig 可以看看 i/o 流量，先确认自己侧是不是真实消耗了

很不错。等会下班追剧去

@lindenYou
在技术设计评审环节需要有人把关，如果后端没有人懂这个或者后端 leader 也不想管，要么他换人，要么你跑路。

楼主你好，我有几个问题。这个 JD 招的是全栈吗？其中后端语言栈是否只有 node.js ？
工作中对英文的听说能力是什么要求呢

很多边界问题 没有唯一的准则。大多根据
1. 谁受益谁来做
2. 两边都能做的情况下，衡量 ROI ，很多情况下需要有话语权的人判断和拍板
3. 如果你水平足够，代入到领导的视角，如果你是领导，你会让谁来做？此时你会脱离自身利益，看问题看得清楚些

回到你的具体问题
1. 数据结构：前后端应当维护一个资源结构并达成共识。后端返回共识的结构即可。后面 UI 有变动导致的 数据渲染（表示）层变动，前端来处理就好。即，不考虑 UI 具体结构，只从资源关系上定义好数据结构。

2. 用户输入验证：
- 前端：应当最大限度把不合法的请求拦截掉，避免对服务端发出无用请求，从用户体验来看，也会更好。但一些重逻辑的判断，可以透传给后端判断，避免前后端不好维护这类重逻辑。
- 后端：必须要判断。永远不要相信用户的输入时第一原则。微服务中的内部服务间的“前后端” 则看具体设计和取舍了

3. 并发和防刷
- 前端：要做。考虑的是用户体验 和 对后端压力的缓冲。
- 后端：看具体需求决定，有些无关痛痒的需求就没必要加锁了，前端做了就行。涉及金钱或者会影响需求的正常实现的，那就必须要做了，否则就是 bug 了。