所得税的 APP 里面在进行年度申报的时候是能看见年终奖的，是在让你选计税方式的地方。如果任何地方都看不到，可能是单位没替你报税，你需要自己报税。

以前都是单独计税，以后要变成算在全年收入里一起计税，现在是过渡时期，所以年终奖这一部分是算在全年收入里一起计税还是单独计税，你自己可以在 APP 里选择。

可以根据税收计算规则来算一下是算在全年收入里计税还是单独计税划算，一般是单独计税税金少，工作单位的财务通常会帮你选好税金少的计税方式来帮你缴纳好年终奖税金了，所以如果你在 APP 里选的计税方式跟单位财务选的一样，理论上你就不需要退、补税。你可以先选一种试试，后面看看是否需要补税，如果需要补的话就返回上一步换另一种试试。
当然自己报税的部分肯定需要自己补税。

1. JS 是个历史非常长的语言了，语言特性受一些同样历史非常长的其他语言影响，同时又产生了一些历史包袱；比如 C 和 Java 也都有相同的自增自减特性，计算机专业大多会首先学 C ，自增自减放左边放右边不一样的这个特性也是一个比较重要的知识点。
2. 一个人对一个知识了解越少就会越通过主观感受去评判，了解越多就越尊重客观事实；语言没有好不好，只有适合不适合、习惯不习惯。
3. JS 是一们特别灵活的语言，灵活的代价就是对开发者要求很高，开发者得思考运行结果、异常风险，以及要在众多实现方案里选出一种最合适的；也存在着一些语言写出来的代码千人一面，但同时也损失了灵活性。
4. MDN 上关于 JS 的资料非常全，比如自增运算符的： https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/Reference/Operators/Increment ；建议不管是 JS 新手还是老手都仔细看一遍 MDN 上关于 JS 的文档，即便大多内容都已经了解，边边角角的地方往往会给你一些惊喜。
5. 团队协作写代码的话，风格标注和文档 /注释都很重要，因为代码主要是用来给别人看的，其次才是用来运行的，可以结合团队成员的平均水平，来规定哪些写法可以用哪些不可以用，然后大家一起遵守就好了。

Hydro Coach PRO ，emmm ，大多时候都是直接忽略提醒……

正压通常有固定的进风口，而且只会从这个口进风，所以只要把这个口的防尘做好，整个机箱的防尘效果就会很好了；负压就是会从任何缝隙进风，无法集中做防尘处理。

品牌机很多都不讲究正压负压的，甚至连风道都不合理，散热合不合理全看运气。

@AllenHua #2 RedHat 系和 Debian 系确实是两个非常庞大的发行版族系，但其他族系也是有不少的，而且很多有自己的包管理方案，发行版族系部分可以参考维基百科上的这个图，你可以发现 Arch Linux 是自成一系的： https://upload.wikimedia.org/wikipedia/commons/b/b5/Linux_Distribution_Timeline_21_10_2021.svg

你找的图里的信息其实并不严谨，这里面杂糅了好几种概念（可能我讲的也不是完全严谨）：
包文件格式：.rpm 、.deb 、.pkg.tar.xz 这些；
包管理器：RPM(没错，跟包文件格式重名)、APT 、pacman ；
包安装器：dpkg ；
包管理器指令：yum/dnf 、apt-get/apt/aptitude 、pacman/makepkg/yay 。
bash 是 Shell ，不属于包管理器，仅仅是用来执行命令和脚本，比如简单把程序文件复制到系统目录，并进行简单配置，这个操作通常是不受包管理器控制的。

举个例子，比如对于 Debian 发行版来说，aptitude 工具会调用 APT 包管理器去软件源检索软件包和依赖，并下载下来，再使用 dpkg 安装到系统上，同时 APT 会对软件进行初始配置（ configure ）。
又比如可以在 Arch Linux 发行版上，使用 yay 工具调用 pacman 包管理器在软件源检索软件包和依赖并下载下来，或使用 yay 工具来下载 PKGBUILD 文件再使用 makepkg 来编译和打包，最终都使用 pacman 包管理器把包文件解包、安装到系统上并进行初始化配置。

在没有包管理器的发行版上，或者自己要安装的软件不支持使用包管理器安装的方式，你可以手动使用 make 等指令来编译软件文件，再用 cp 等指令把已经编译好软件包的文件复制到相应的系统目录中，并使用 vi 等编辑器来创建初始化配置文件；这个重复性过程也可以写成 Shell 脚本文件（如.sh 文件）自动化完成。

干活都能干，有轮子就用，没有轮子也都可以自己造，用哪个顺手就用哪个，我还用 JS 写后端呢，任凭很多人觉得各种不好，我基本都能达到我的预期目标。

对于个人来说，我可能更多考虑好不好找工作，这个不同行业不同地区的情况差别可能很大，可以参照一下当地的招聘平台的情况再做结论。

另外任何项目发展到一定规模，统一技术栈的成本可能就越高，比如涉及到大数据部分了你 C#用得再溜，可能用 Java 成本会更低。再如涉及到游戏领域，你 Java 再怎么牛，可能还是避免不了用 C#。
那么最终的结论就是，我全都要。

我个人认为，beimenjun #33 很有可能是认真的。

咨询心理医生不代表就有心理疾病，也不代表就有精神问题，我自己有不舒服的时候就会去医院挂个号看一下，虽然大多时候医生都跟我说没毛病，但这个结论可以让我自己安心。所以如果这件事情对你影响比较大，心理医生没准可以帮你疏导一下，只是个建议。

当然，如果这种回复会比较令你反感，那么我道歉，并没有恶意。

我是觉得 Google 的自动 AI 分类功能很好用，特别是面部识别，可以很方便找某一个人相关的所有照片。

如果你只是因为这个 bug 而打算放弃，也可以尝试给他们客服说一下这个问题，能解决就继续用，解决不了就彻底无缘了。

但确实私人的东西放到云上不大安全，不管是宣称多么“安全”的厂商，这个不分国内国外。

我现在是所有照片都放在自己的 NAS 上，也尝试用过 PhotoPrism 这种有 AI 识别能力的管理工具，但效果都跟 Google 的比起来差太多了。

我是觉得 processzzp #8 说的话，乍一看确实有点让人难以接受，但实际上也不完全没有道理。

我为什么这么说，是因为我个人觉得：
1. 如果我穿衣服觉得衣服变小了，会第一时间怀疑自己是否胖了，然后再怀疑衣服是否洗缩水了；
2. 正常情况下如无必要，是不会刻意改小衣服的，因为一旦穿不上了，可能没法改回去，衣服就浪费了。

在我个人的认知里面，可能很多人都会如此认为，所以不免会觉得题主的问题会有些奇怪。

当然也可能是题主有前因后果没有交代，以至于较大信息差让一些人觉得很奇怪，没准题主交代了事情背景，这个问题就可以被合理化了。

自己部署 OSS 不如租个 CDN ？反正都是要花流量钱。

另外也可以看看有没有可以用在你博客上的图床，就是不确定可靠性。

有必要。

可以去了解一下大学计算机专业有哪些课程，然后找书自己看，也可以去 B 站上找大学的公开课。

计算机基础打牢了，可以让你学习新知识更加容易，而且解决问题的思路更广。

我曾经在台式机上，把一块装 Linux 的硬盘从 Intel Core i7 4790k 的电脑上直接拆下来装到 AMD Ryzen 7 3800X 的电脑上，可以直接用……当然也有运气的成分。

笔记本的话比较麻烦的就是硬件相关的驱动和配置，如果不是装系统就直接能用的那种，需要你自己去调校。

你可以把硬盘换过去试试，或者用个 live 系统把旧硬盘上的数据直接全盘 dd 到新硬盘试试。

国内企业里，阿里的开源项目是最多的，但同时烂尾项目也是最多的，这些项目了解了解思路学一下就可以，真正要用到生产上的话得充分考察一下。

任何架构都是有适用场景和不适用场景的，比如加一层 BFF 可以让后端专注于资源和核心业务，前端可以更灵活地实现表层业务，如果后端只服务于这一个前端的话，加一层确实意义不大，因为 BFF 的工作后端也可以做，但如果后端是被很多业务团队的前端共用的，加一层就可以让后端仅提供通用 API ，细节让前端根据自己的业务特点自己在 BFF 层定义，从而有可能可以节省开发成本。

很多东西的存在不是为了完全替代其他方案的，而是在某些情况下比其他方案更适合，比如一个项目需要加一个 BFF 层来节省开发成本，而且 BFF 层要让前端团队去负责，那么让精通 JS 的前端在写 BFF 的时候肯定也是首选同样用 JS 的 Node.js 技术栈，再让前端去学 PHP 、Java 成本就太高了。

你觉得多余，是因为你目前的项目场景不适合这个方案，不一定代表这个方案在任何场景都多余。

push 和 delete 没有顺序关系，不管先 push 还是后 push ，item 都是引用的 item ，你就是把 item 给赋值到全局作用域，在其他域进行 delete 也是可以删除 parent 这个字段的。

看到有人说一路向西我就放心了乛◡乛

P.S.看片之前注意看简介。

如果长期在某个地方的话，应该可以去当地的户籍派出所办理身份证续期，我前几个月就是去附近派出所办理的异地身份证续期，制证需要一段时间，我当时好像是等了两周，到时间拿凭条去取就行。你可以打当地 12345 或派出所电话咨询一下。

在 HTTP 标准中，400 代表服务端无法理解客户端的请求，按标准来说，所有业务当场景中，这一定是不应该出现的，正式客户端的任何请求都应该是在预期范围中的，有错误也应该是业务上预期存在的可能性，即业务上预期的错误应该返回 2xx 状态码，并在返回载荷中说明是什么错误。

除非项目自己将 HTTP 状态码进行了重新定义，比如像 REST 风格中，将状态码和业务捆绑到一起，此时 400 不光代表 HTTP 协议上的错误，也同时代表业务上预期存在的错误。

所以看你们使用状态码是遵循 HTTP 的标准定义，还是有一套自定义；如果是标准定义，那么返回 400 就不是好不好看的问题，而是程序确实存在问题；如果有自己一套定义，就得看当前情况下返回 400 是否合理，合理的话就没必要处理。

另一方面，浏览器通常是严格遵循 HTTP 标准的来设计的，也默认网站开发者是遵循 HTTP 标准来设计网站的，那么不管你们项目如何自定义状态码，浏览器一定认为 400 是个问题，所以会在开发者工具中给予提示。

就好比是消防传感器（感烟）会对室内吸烟行为有反应，吸烟的人知道现在没发生火灾，但消防标准规定传感器就应该在探测到任何烟雾的情况下通知报警。

浏览器的行为是浏览器开发者在代码里定义死的，除非你获得浏览器代码自己魔改，并给用户提供魔改版的浏览器安装包，否则是没法改变浏览器的行为的。
开发者工具是提供给浏览器用户的工具，而不是提供给网站开发者的工具（虽然有时候两者是同一个人），网页上的代码无权控制开发者工具的行为。

Node 使用 VM 来运行程序的，这玩意的设计初衷就是让用户把精力放在业务上而不是资源管理上，所以有很多内置的优化策略，以及复杂的 GC 策略，对于用户来说是黑盒，最可靠的方式是进行压测，取个大概的资源数量级。

如果对内存使用有精确要求，建议使用可以明确操作内存的语言，比如 C/C++。

接口不泄露也要做好鉴权，鉴权做好了泄露也无所谓。