应该不会有什么大的进步，要代码提示的话上 Github Copilot 试试。
参考隔壁，有了 TypeScript 后，IDE 推导 JS 的能力就强了很多。但我感觉不会有 type python 这种东西。

骗到一个算一个。

Nodejs 官方根本没有什么中文网。这东西是山寨的。正宗的是 nodejs.org

刚学 node 的时候误点进去看了下。就是纯翻译，翻译的不好还不及时。
看核心直接 node.dev/learn ，api 要看这种机翻的话还不如去直接百度下算了。199 我真的笑出声。

买的盘烂，用 sata 也好不了

同意#1 ，两种模型其实并不是非常和谐的。
我现在都是用 DO 、PO 对应数据库单表，然后再转换成比较面向对象的结构。

要考虑。不过不是前端考虑。
所有前端发过来的东西都是不可靠的。敏感数据鉴权，限制访问次数都是后端的事。
前端做不了，浏览器控制台看网络请求，api 一目了然。你要回避就得在请求体里再加密包一层，但前端加密的密钥还是藏在前端代码里的。

有些网站，比如 github 、v2ex 还会提供开放 api ，允许别人直接访问。这时候连前端都没有。
代码混淆什么的可以做，不过得在后端已经做得很安全了以后，锦上添花罢了。

最后，打开你平时上的网站：百度、狗东、B 站、支付宝，甚至是竞争对手的网站，看看人家咋做的。

①游戏开发相关，性能要求高 ② 跨平台 ③个人学习
这种情况能放心推荐 Flutter

HTML 、CSS 、JS 确实是目前比较好的跨端方案，但写的一般就是增删改查应用。

电脑：MacBook Pro 2019 Intel 16 寸
键盘：宁芝 82 键
鼠标：微软人体工学大馒头（在我推荐下已经有 3 个同事入了）+ Magic Trackpad
外接显示器：U2720QM ，单屏
扩展坞：贝尔金 雷电 3

合盖用立式支架，所以需要独立触摸板。因为有扩展坞，插一根雷电线就可以了。
但实际上并没有那么优雅，每次都是笔记本开盖，然后插上线，等显示器输出画面，再合盖，放到支架上。（如果直接合盖插，那么显示器就没有信号，至少 Catalina 的时候还是这样的，有时候搞不好还会死机）

其实我还有一个 2k 的显示器，但 mac 的 2k 支持很差，使用了 one-key-hidpi 又有鼠标消失问题。于是现在单屏了。mac 双屏应该要双 4k 才好。
另外体验也不好，我在学习的时候，经常是左边屏幕放 B 站视频，右边 Typora 做笔记。如果写了一点笔记，然后想暂停下视频。必须得在视频位置点一下先让 Chrome 获取焦点，等一小会儿再点第 2 下。如果直接双击就会全屏、只点一下 Chrome 获取焦点了，但视频还在放。本来以为是 Magnet 的问题，后来发现双屏也这样。
准备换回 Windows 了。

遍历 codepoint 对比下。
我项目里都是用 utf8 without bom 的。

我也看见了，看来是今天刚上的

设置-->设备偏好设置-->系统-->USB 模式，选兼容模式试试看？
我猜的

我也觉得响应式好，但这个难度很高。
自己设计肯定搞不出来。

“有的语言会把时间戳定义为当前时区自 1970-1-1T00:00:00 到现在的毫秒数”
根本就没有语言这么做，再者说就算这么做了，也跟我时间戳（无论是毫秒还是秒）这个普遍概念没关系了。

@nothingistrue
[1-中国标准时间.jpg]( https://dcsuibian-public-resources.oss-cn-hangzhou.aliyuncs.com/img/1-%E4%B8%AD%E5%9B%BD%E6%A0%87%E5%87%86%E6%97%B6%E9%97%B4.jpg)

[2-亚马逊标准时间.jpg]( https://dcsuibian-public-resources.oss-cn-hangzhou.aliyuncs.com/img/2-%E4%BA%9A%E9%A9%AC%E9%80%8A%E6%A0%87%E5%87%86%E6%97%B6%E9%97%B4.jpg)

你看看在切换时间后，时间戳这两个数字差了多少？ 36438 毫秒，也就是 36.4 秒，就是我在第一个运行完、截图、改时区等操作花了一会儿而已。

@nothingistrue
ISO 是国际标准化组织，又不是只面向计算机从业者的，8601 是规定了显示方法。数据的存储和显示相分离的设计原则不是再正常不过了吗？
我一开始不就说了使用“毫秒”级时间戳。确实时间戳没有国际标准。各种语言都可以轻松地处理。
Python 的 time.time()，Java 的 System.currentTimeMills()，JavaScript 的 Date.now()，也就差一个 1000 处理。推荐使用“毫秒”时间戳只是因为整数比浮点更好处理罢了。
最重要是，处理过程中没有涉及到任何“时区”相关的东西？

这个数字只跟时间点有关。如果你没条件找个其它时区的人跟你一起试的话。至少换个系统时区再试试，关键是



你到底有没有试过？

@nothingistrue 扯远了。
回到用 long 存时间戳的问题上，假如现在有一台 MySQL （无论在哪儿），Java 程序 1 在北京，Java 程序 2 在纽约，它们都连接着这个数据库。

实验 1：
先是北京产生了一条记录，然后 10 分钟后纽约产生了一条记录。Java 程序都使用 System.currentTimeMillis()将得到的 long 数字存入数据库。那么这两条记录差的大概就是 10*60*1000 毫秒。无论你是否设置了 serverTimezone 参数，可测试。

实验 2：
使用如下 Java 程序插入一条新纪录。
String url = "jdbc:mysql://localhost:3306/test?serverTimezone=UTC%2B8";
Connection conn = DriverManager.getConnection(url, "root", "password");
PreparedStatement stmt = conn.prepareStatement("INSERT INTO record(`time`) VALUES(?)");
Date date = new Date();
stmt.setObject(1, date);
stmt.execute();
stmt.close();
conn.close();
在保留和去除 serverTimezone=UTC%2B8 这个参数的情况下分别插入一条数据。那么你在数据库里看到的时间差别就很大。这是因为虽然 MySQL 底层虽然用了存整形的方法存时间戳。但你 insert 的时候仍然得用字符串：
INSERT INTO record(`time`) VALUES('2022-07-13 00:00:00')
这就有了借助时区的转换过程，然后就会有问题。

@nothingistrue MySQL 的 Timestamp 会在你 select 帮你格式化成文本帮助你阅读，格式化时就会用到时区信息，但底层的数字是没有的时区信息的。

对应的，你套上 UNIX_TIMESTAMP()函数，然后再看看。
SELECT
UNIX_TIMESTAMP(CURRENT_TIMESTAMP()),UNIX_TIMESTAMP(LOCALTIMESTAMP()),UNIX_TIMESTAMP(UTC_TIMESTAMP()),UNIX_TIMESTAMP(NOW())
FROM DUAL;

世界上各个时区的人在同一时间点调用 System.currentTimeMillis() 拿到的是同一个数字。
那用这个数字来表示时间点就不会因为时区、显示而产生歧义了啊

@nothingistrue 不带时区的。你可以先正常运行一遍：
System.out.println(System.currentTimeMillis());
然后，换个时区再运行一次，你看看这两个数字差了多少就知道了。（毫秒）

时间戳只是针对某个时间点的偏移量。只不过这个时间点是 UTC 1970 年 1 月 1 日 0 时 0 分 0 秒
完全可以说时间戳是从 UTC+8 1970 年 1 月 1 日 8 时 0 分 0 秒 起至现在的秒数，这俩就是同一个时间点。
只不过挑一个基准时间点，总归要挑个规整点的罢了。

漏了这个
https://www.liaoxuefeng.com/wiki/1252599548343744/1255943660631584