罗小黑战记

ORM 的类型安全还体现在查询条件的处理上。

比如对于一个 有 Age(Int) 字段的 User 表：
不使用 ORM：select * from User where age = 233 、select * from User where age = haha ，
这两句在代码里实际上是字符串，都不会报错

使用 TypeORM：const user = await userRepository.findOneBy({ age: 233})、const user = await userRepository.findOneBy({ age: 'haha' })，TypeScript 能告诉你第二句的参数是非法的

使用 gorm: db.Where("age = ?", "22").Find(&users)、db.Where("age = ?", "haha").Find(&users)，go 语言并不能判断第二句的输入有问题。

ORM 的类型安全还体现在查询条件的处理上。

比如对于一个 有 Age(Int) 字段的 User 表：
不使用 ORM：select * from User where age > 233 、select * from User where age > haha

当然首要是为了类型安全 (Type Safety)，然后才是防止 SQL 注入、逻辑复用。

ORM 的一个重要功能就是将 数据库 里的表结构 转化为 对应语言的 Entity (Persistant Object)。
如果不使用 ORM 的话，用 SQL 从库里捞出来的数据得手动加类型断言，这个类型断言得随着每次 SQL 改动或者 表结构而变动，非常不容易维护。

ORM 的另一个功能也是 api 代替 sql 语句的重要意义是：API 抹平了不同数据库之间的差异。比如 mikro-orm( https://mikro-orm.io/)，同一套 API 支持了 MongoDB, MySQL, MariaDB, PostgreSQL and SQLite 。用楼主的话说就是换个 数据库 SQL 语法 又不一样了 ，只有 ORM 的 API 是不变的。

我个人不喜欢 GoLang 的一个重要原因就是 Go 的多数 Orm 因为语言的缺陷无法实现完善的类型安全（对比 TypeScript 的 TypeORM 、C# 的 Entity Framework Core ）。同样我也不喜欢 Java 的 mybatis 。

我是从初中开始听。
最开始接触的是 河图、老妖、小曲儿、董贞、少司命。少司命的专辑《以剑之名》几乎都是灰原穷编曲。不久后听到银临的专辑《腐草为萤》，一看编曲又是灰原穷。刚听到《锦鲤抄》《泸沽寻梦》就开始循环了，也是那时候关注的银临。
后来银临出了一首《牵丝戏》，相当破圈，差不多这时候银临已经是古风圈顶流了。银临写的歌真的很好听。个人评价银临最好的作品是《东风志》，各方面都挑不出毛病，也是古风圈争相翻唱的曲目。

这两年古风圈也有很多新面孔，比如 黄诗扶、陈亦洺，既能写曲子，唱的也好听。少司命写的《百战成诗》想必大家都听过不止一遍了。
这些年来其实可以看到古风圈越来越好了。
圈内知名的太太（银临）已经可以做音乐养活自己了，很久之前的 5sing 大家都是用爱发电。有的太太（泠鸢 yousa ）甚至开始做 vtuber 了。

可以把 psd 上传到蓝湖，然后你就可以愉快地对着蓝湖取尺寸了

C# 宇宙第一。
TypeScript 也很不错，我称之为 C#-Lite 。而且 TypeScript 能无缝衔接 JavaScript 生态，生态非常繁荣。

Anders Hejlsberg YYDS

个人感觉在现代前端应用把 html 结构和 css 样式分离就是个错误。
Flutter 、SwiftUI 、WPF 都是直接在 element 上加样式的。

关注点不分离之后开发和维护轻松多了。
目前使用 Utility-first 的 tailwind 、windi 或者 css in js 的 emotion 等库都能轻松做到关注点不分离。

css in js 的写法没有普及令我感到诧异
jsx 作为一种编程语言，自然有与其对应的样式写法，类似这样: https://emotion.sh/docs/css-prop

这个写法明示了样式目标元素在 DOM 中的位置，也不用给维护对应语句提供定位

如果样式与结构分离，所有 css 胡乱堆砌在一起，通过 className 与 element 绑定，就是一座屎山。无数人抱怨 CSS 不可维护，就是找不到应该从哪里入手修改，只能碰运气搜索一下，不久就放弃了，然后在文件末尾新启一行，糊上新的屎

我自己给常用的 200 个网站编写 UserCSS （不是），其中最长的(刚好是本站)有近 700 行，短的也有几十行，如果没有 css in js ，维护这些 CSS 不可想象

这种写法如此自然，以至于我想象不出为什么很少有人这么写，不是本该如此吗

nodejs 的 ORM 都是能在项目启动的时候自动建表的。
比如 TypeORM 把 synchronize 置为 true 。
这种方法是最友好的，但是不太安全。正经生产环境绝不会开 ORM 自动更新表结构。

就我个人的经验来看，nodejs 后端一般是先在本地或者测试服用 ORM 的自动建表功能建完了之后，用 DataGrip 或者手动 dump 把表结构导出成 SQL ，人眼过一遍，再找新的环境跑一遍，再把 SQL 部署到线上。真正对线上生产环境改动的 SQL 都是经过反复测试的。

具体到楼主这个小项目，我建议楼主要么开 ORM 自动更新，要么把运维的活也揽了。

转念一想，其实大家早就看不惯 React 这种函数式的贪婪更新机制。
所以后来的 Vue3 、Svelte 、Solid 都是监听变化按需更新，可以说它们比 React 更 reactive ，性能比 React 好不少，也没有到处 useMemo 、memo 的烦恼。
vue3 是我觉得最舒服的，reactive 对象可以作为全局变量存在于组件之外，这样极大方便了组件间通信。不过话说回来，全局变量还是得小心地用，不然会有内存驻留的风险。

你说的很对，用全局变量再加上 render-optimized 是个不错的方案，valtio 就是这么干的
https://github.com/pmndrs/valtio

powershell

这个软件我经常安装卸载。
每次看到大家都夸它好用就会去安装，安装完了发现它对我来说并没有提升效率就卸载。

alt + space 呼出搜索栏，我用系统自带 win + s 照样呼出搜索栏，而且 UI 上 windows 的搜索栏比 utools 好看不止一个档次。
各种小工具其实也挺好用的，但是大部分我能直接在 windows 商店里找到一样的，UI 上还比 utools 好看不止一个档次，何必让 utools 来做我的应用商店？

归根到底 现在的 Windows 已经足够完善了，并没有哪个方面需要 utools 来补足。

我见过类型体操最 6 的项目：
https://github.com/codemix/ts-sql

这时候就体现出 GraphQL 的好处了，后端还是直接抛从数据库里取出来的对象，前端需要什么按需取就行了

想勾搭设计师的话可以去站酷
https://www.zcool.com.cn/designer

楼主这个情况我觉得可以考虑深入学习 Node.js 。Midway 、Nest 搞起来。