因为它本来就应该死循环, 设计上这样写就应该死循环!

你自己是销售吗? 这些应该是领导和公司销售需要考虑的问题, 归属于市场部管, 如果你是做技术的, 那很难转进去, 这个行业都是熟人相互介绍, 相互引进, 许诺关系费用, 一环套一套.

我们的设计原则是: 全部小写, 然后使用-分隔, 不需要 value 参数, GET /config/system-maintaining, 很多国际互联网企业的 API 也是这个规范, 另外并不是所有的 API 都适合 RESTful Style, 使用动词风格也没啥大的缺陷

@amuyue 如果你使用 UUID 作为主键, 然后需要频繁的查询, 可以使用有序的 UUID 生成器算法, 这种算法可以保证随着时间递增, 从而避免 UUID 默认无须导致的索引更新时候到性能损失, 如果查询非常频繁, 更新很少, 那就无所谓!

你的代码非常奇怪, 一般在 EF Core 中, 正常的写法是
public class Entity: IEntity{
public string Name{get;private set;}
public virtual Point{get;private set;}
}

很少使用 GetXxx 或者 SetXxx 的形式, 另外导航属性默认是懒加载的, 虽然你也可以将其调整为直接加载, 一般还是要手动 Include 的, 接口完全可以定义属性哈

你的代码非常奇怪, 一般在 EF Core 中, 正常的写法是
```csharp
public class Entity: IIterface {

}
```

@ungrown 放弃了, 懒得这特了, 主要是 Mac 连接 Linux 问题太多, 我需要 CUDA 加速查看 PointCloud, 这个没有硬件加速会非常卡, 操作起来极度不流畅, 画面传输的软件在内网还可以, 但一旦跨国(我的 Linux 服务器不在大陆), 就会非常看, VPN 和机场我都测试过了, 延迟是无法接受的, 我现在不折腾了, 重新在家里搭了环境. Linux 的桌面环境我是收购了, 我 10 前用的时候就问题多多, 10 年问题还是多多, 所以我还是只打算使用它的 bash shell, 彻底放弃它的图形, 不想折磨自己, 不是 ROS 这个破软件, 我早就放弃了折腾图像界面了!

另外 xrdp 在 Ubuntu 有巨大的坑, 我在 GitHub 仓库提到 issue 过了 2 年了还是没有解决, 超级卡(Ubuntu 18 好点), 其它版本的 Linux 发行版问题不大, 就是在 Ubuntu20.04 的默认桌面环境上几乎失去可用性. 你自己去 xrdp 的仓库下看看.

别折腾了, 都不好用, 我就是这一套, 已经搞得快奔溃了!
如果在内网, 直接用 SSH 加 Xming, 外网都非常难用, 我换个各种方案, 没有一个靠谱的! 如果没有 3D 程序, 特别是游戏这种就还好, 如果有需要显卡的 CUDA 的, 就是一个巨大的坑, 我已经爬出来, 彻底放弃这个破玩意, Windows(A)还好, 如果 A 是 Mac 就更加坑爹, OpenGL 死掉后, 都没法使用显卡硬件加速到了

@shenhualv7 VSCode 没啥文件打不开, 包括二进制文件都可以通过插件直接查看 Binary 或者 HEX, 文件内容和后缀没啥关系, 你直接将文件拖入到 vscode 就好了. 找个博客好好理解一下字符集, 编码规则, 存储编码, 这个对写代码还是有点作用的, 另外你这种混合编码写入到一个文件是不好处理的, 怎么改编码都会得到错误结果, 你必须知道在字节的多少偏移位置开始是另外要给文件, 然后写代码, 自己统一转换为同一种编码! UTF-8 的 BOM 在 Windows 上是个历史遗留问题, 其它的 UTF 存储格式的 BOM 是必须的, 将不同编码的二进制流写入到文件的确需要小心!

原型继承和基于类的继承有本质的不同. 你将 JavaScript 的对象理解为一个字典就好了, 而 Java 这种基于类型的继承是非常复杂的, 需要考虑静态绑定, 动态绑定, 类型对象, 类型对象指针, 同步索引等等. 本质上就是性能问题, JavaScript 的继承就是一个从. __prototype__对象上递归向上查找属性(方法+索引器是比较特性的属性)一个设计, 因此在读取上内存可以共享原型链上的数据成员(写入不可以), 而 Java 这种基于类的数据是不共享的, 只有方法代码可以共享.

不知道你写的二啥, 后面一段非常奇怪, 这个是 "constructor Object constructor Function constructor null " 什么意思?
JS 对象当然可以没有原型, 原型只是原来实现继承的. 就是解释器实现的一个魔法属性罢了.

看看有没有办法减少上下班的行李. 自己买自行车很麻烦, 除非你可以从公司骑行到家. 看能不能个相关部门提下意见,我家重庆那边地铁附近有电动助力单车, 我觉得是个解决问题的好办法, 自行车也不适合带比较重的行李, 电动的就好点.

我每天跑步 7 公里. 1 公里 So Easy, 走路的速度也在 10 分钟内可以搞定. 这点路都不想走的话, 迟早腰椎, 劲椎病可能找上你哦!

另外我发现记事本是可以正常打开 GB2312 和 UTF-8 的, 你先确认一下你的文件实际使用的编码是什么, VSCode 的右下是可以修改打开文件的编码方式的, 自己换几个试一试, 常见的就是 UTF-8/UTF-16/GB2312/GBK

先用正确的编码打开, 然后保存成 UTF-8 编码, 另外记事本应该是可以正确识别 UTF-8 的, 你可以使用 VSCode 开文本文件, VSCode 应该是可以猜测出你的正确编码, 然后按照一楼所说, 修改编码为 UTF-8

位置大概在\resources\app\extensions\markdown-language-features, 这个里面将 java 等效于了 JAVA, 你可以在加一个

修改 VSCode 的 Markdown 插件的源代码, 将 Markdown 的 Code Block 识别 Parse 中的硬编码 Java 改成你写的那个. 没啥好的办法.

Action 的名字按照正常 Pascal 规则.
最终路由输出规范化为: user-info/follow, 路由单词全部规范化为小写.
query string 按照实际需要保留大小写.