明天要做个退款 /支付失败后恢复库存的功能，gg

有对抗就肯定紧张啊，除非这种对抗是无法通过临场发挥来改变结果的，同时无需提高自己的智力 /技术水平的，才能即对抗又休闲

我们来对抗 v 站签到天数好了

自用的话有 jsonschema 直接生成表单的轮子，真香
面向用户（包括 b 端用户）的话还是慎重吧

邮件发码的

mini2 锁电问题京东换了一次还是没好，换 charge4 了，同样的音频线底噪也比原来小了，真香

@FrankHB 抱歉基本没看懂你在说啥，如果你觉得 toml 还不够好，可以举一些你觉得比 toml 优秀的方案来让大家学习一下么？

数据交换和配置管理是非常不一样的两类需求，数据交换优先的是机器可读和性能，可选的是人类可读，没用的是容易编写，因为数据交换的主要场景是从内存 serialize 而不是手写。而配置管理重要的易编写和人类可读，机器可读其次，性能基本没用除非烂到不可理喻。

你说了是数据交换格式，然而你的 feature list 里面大于 json5 的部分基本都和数据交换无关，而是配置管理的需求，这些需求对于数据交换来说都是无用的复杂性而已（ client 发了个 pjson 给 server，结果 server 还要再请求远程文件才能获取完整结构？安全性和性能都完蛋，更别说 include 本地其他文件了）

看你一直在说注释重要和手写配置，那么反过来说如果你的项目目的是配置管理，那 json 就根本不是一个好的（不如说是最糟糕的）学习对象，建议看（学）看（习） toml 这种更现代的配置语言

还有，我讨厌这种回复每楼说你不懂其实我的东西很牛逼的楼主，如果楼主你回复我请做好被无视的心理准备

1. 没有归档，只是说了 move to gitea，但如果不打算再更新 github，确实应该归档
2. 有多少关注有多少人用和这个项目明天是否继续维护没有必然关系
3. license 是自由的，你可以自己 fork，可以自己把 gitea 的代码搬运回 github 上只要保留原有的 license 都没问题
4. https://xorm.io/ 默认英文结果却迁移到 gitea.com 自相矛盾，顺便 Footer 写 license MIT 结果点进去给你看个 BSD3 也是

@mcfog 十来个**人的**专家小组

因为当你有一万个程序员员工，搞一个语言需要的十来个专家小组就算不上什么巨大的投入

已有技术换语言造成的难度对开源社区的后入者来说是天堑，但对有公司级别行政力的公司项目来说就不存在难度，只是成本而已

那么为什么那么多公司做了呢？因为难度不高，回报轻易超过成本。那么为什么国内做的少呢？因为引领不了社区，勾不到社区投入，回报路径不通

打 bash 回车试试？

promise 没学明白就拿 async await 来写代码就这样了

用 new promise 来包别的 promise 已经是反模式了，还再加上 async await

这代码没治了，从头重写吧

什么不仁不义的没意义，你要做的是收集更多的情报、证据和法律知识，结合自己的情况来看下一步，而不是在有一百种更好的做法的时候就直接考虑双输的报复性手段

公司对你没有高要求，不代表你就不能用更高更好的技术来完成公司的项目

都工作两年了还觉得自己是个学生？你已经是个成熟的社会人了，该学会自己成长了

所以你觉得不想要看书的建议，但你现在也就自己看看书？你觉得看书对你成长足够了，那就继续看书；觉得不够，那要么别钻在书里，要么好好想一下为啥看书成长不起来

https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution

上传包给 apple 签名，或者等作者发布更新

又是一个不遵守 semver 的项目

因为有饭吃是能写代码的前提啊。

我就喜欢订阅制。订阅制保证作者有饭吃有计划来更新新功能和维护，而不是在被迫刷版本收费升级和饿死之间两难。

为什么好用的工具容易死？因为赚不到钱，订阅还被骂，人不吃饭，就会死。

至于你现在能免费用到的好用的东西，要么是有别人（或者企业）出了更大的价钱养起来了，要么是其实根本不需要维护，凭早期作者靠爱发电的累积就行