测试了下, 目前来说比较智障, 不过他居然会画图, 只要让他画画他就会尝试用 basic 字符画画, 画猫是一绝...

用好些年了上班摸鱼首选, 平替几乎有没有, 喜马拉雅的会员是这些里最便宜的资源也是最多的, 每年各种联合会员, 我也是充到 26 年去了, 将就用吧

要定期检修的, 我司老楼的电梯年级比我大了, 照样正常运行

没有 我美区 30 刀许久没花出去了 全是整的各种买断游戏

一种方式是直接按静态类处理, 扩展性更好些. 任意自增方法或属性

```ts
class TsEnum {
public readonly code: string
public readonly name: string
constructor(code: string, name: string) {
this.code = code
this.name = name
}
public static getInstanceByCode<T extends TsEnum>(this: new (code: string, name: string) => T, code: string): T | null {
const enumValues = Object.values(this)
for (const enumValue of enumValues) {
if (enumValue instanceof this && enumValue.code === code) {
return enumValue
}
}
return null
}
}

class SystemEnum extends TsEnum {
public static readonly FOO1 = new SystemEnum('foo1', 'FOO1')
public static readonly FOO2 = new SystemEnum('foo2', 'FOO2')
}

console.log(SystemEnum.getInstanceByCode('foo1'))
console.log(SystemEnum.FOO1.name)

```

文明 6 11 块 巫师 3 14.9 要啥自行车, 骨折价的全部买了再说, 万一后面想玩呢

@BiChengfei #11 天真, 信我, 这种口你一开, 业务就会把 大前天/上上天/138 天前/前年 Q1/上个财报年 这种鬼需求给提上来, 具体是否适配就看你部门领导是否强硬愿意扯皮了

试了下是的, 官网和小程序端都挂了, 打不开任何文件, 但 WPS 可以打开相同文件, 应该是金山文档端的鉴权挂了

@shadowyue 同意, 日期相关的不建议语义化, 尤其后台表单, 部分业务人员操作是真的无脑操作的, 出问题直接甩锅技术部门, 给几个常用选项就可以了,例如本月/上月/半年内这种还好说些

好东西啊, 求个关键字, 我也想炼丹玩玩

中老年单身狗见不得这个...真好啊

之前基于 uniCloud 做过个项目, 初期开发的确很爽咔咔整完, 后台基于 uni-admin 开发, 生态绑架非常明显, 后期运营起来后, 发现首先运营脚本就是个麻烦事, 运用老哥攒的一堆乱七八糟各种语言的脚本根本没法用, 全部得重新写, 还有一些其他系统甚至语言开发的系统对接, 原本可以同一台服务器部署端口调用即可, 现在得额外适配或转发, 不然太慢了(云服务调我们私有服务器). 一堆大大小小的问题.

目前总结下来唯一优势是不用考虑并发问题, 小程序初期大规模推广时只管充值不用大半夜起来重启服务器或者扩容这种.

至于低消我 19.9 我觉得 OP 的比喻是不对的, 首先正常人除了外包老哥没人会没事整 10 个小程序挂那对吧...这玩意矛盾点在于同等价格的轻量云别说 10 个 20 个我都随便挂, 大家都是吃灰, 但是云开发只能用来做业务.对于个人来说.

要是纯按量计费也是不错的选择, 至少会有很多人愿意尝试, 可这玩意整低消 19.9 起就让人比较反感了.

云开发的问题在于后端管理, 侧重小程序或纯小程序弱后台管理还好, 重后台管理, 对接就是个麻烦事, 该有的一个都跑不了, 还不如一开始就传统后端了.

自己找个 html, 挂到码云 gitee pages 上就好了, 最方便省心.
参考我这个, 最近才改的, 不过我是挂到自己服务器上

纯 html 静态文件无 js 及外部加载, 12k, gzip 完 6k, 再小的小水管都是秒加载, 全球访问只存在通不通不存在慢不慢问题

https://supermario.vip/

这种实践一般是推出新包名 搭配新 icon 和 新程序名, 确保用户在手机上一眼可以认出是新程序(因与原 app 共存), 之后原有 APP 中添加更新提示引导用户更新, 至于是启动就弹窗告诉用户老应用直接停用了, 还是返回弹窗恶心人但是老 APP 还能继续用就看你们操作了

挂了

PHP 开发体验没得说, 要是团队稳定,或正规公司有专门的规范管理还好.
但问题是 PHP 太过敏捷了, 如果你接手过一些团队变动多次的 php 项目, 尤其外包项目明显, 你就会明白 php 的恐怖之处了. 这些老哥改 php 代码都不过脑子的, 只要不报错就完事 OK.

突然出现的全局变量/全局函数. 业务代码里任何一个地方都能出现的随意跳转, for 循环里查树结构 sql, 变态一点的在模版文件里直接查 sql. 每每想起我接手过的 php 项目就头皮发麻.

最骚的一个操作, 曾经接手一个项目, 客户说性能太慢让我优化下, 我一步一步 debug, 发现前一个老哥在 index.php 引入的一堆依赖里的某嵌套层次很深的地方, 加的日期+域名双重判断随机睡眠 10 到 120 秒...