100 多个脚本, 梳理一下, 做一些技术改造.

1. 偶尔执行的. 改成 django admin 后台配置页面触发. 任务流, 改成 消息队列(生产者-消费者模型).

基于 队列(kafka, rabbitmq, nats 都可以) 解耦: 动作触发(生产者) 和 动作执行(消费者).

推荐 nats, 运维简单.

工作流改造成:

a. admin 侧, 触发动作, send task(参数包) 到消息队列, admin 结束.

b. 消息队列的 监听者 worker, 收到 task, 解析参数, 执行具体任务, 结束.

2. 定时任务, 可以试试 huey 和 django-huey, 支持 redis 监听不同的 queue 来分别监听 + 执行.

比 celery 简单. 注意如果启用了 django 时区, huey 配置也要启用时区, 否则是 UTC 时间.(小坑) 其他使用挺完美.

https://github.com/coleifer/huey

https://github.com/gaiacoop/django-huey

经过上述改造. 如果不考虑高可用, 单副本下, 你大概只需要部署 2-3 个容器实例, 就够了.

需要注意, 如果是 k8s 多副本实例, 需要 MQ 消息 幂等唯一消费, 可以引入一个分布式锁判定, 可以简单用 redis 锁.

上面的方案, 算是比较标准的做法.

不要滥用 django scripts 的一些方便用法. (后期维护一堆烂脚本, 显然是不明智的)

没点进来, 以为说的是 Mojo, 点进来, 是 MoonBit ???

MoonBit 也能来碰瓷 Python? 没活硬增?

MoonBit 在 贵乎 上的营销帖子, 铺天盖地, 到处碰瓷 Rust, Zig.

(讲真, 不打算和 Rust/Zig 坐一桌了, 还是觉得上不了桌? 笑...)

真下头.

东西真好, 自然有人用.

东西不好, 再自我吹捧, 也没人搭理.

劝作者, 好好把静力用在打磨自己的产品.

@Richared #50 Java 项目? 那你还是 idea 吧. 应该没几个正经人用 vscode 写 java. 笑.

(我前面发的讨论, 就不包含 java)

你 idea 跳转都 2 秒了, 这不闹麽. 换啥都不好使.

写 java 的, 无需参与 vscode 讨论. 😄

@Linioi #39 用 vscode 就好. vscode 插件市场, 搜索 python, 把 微软官方的插件, 都装全. 开发体验, 不比 pycharm 差.

(代码补全, 跳转, 流畅程度, GPT 友好, 体验都是完备的)

2025 了, python 开发, 可以完全弃用 pycharm 了.

(作为精通 pycharm 各种技巧, 10 多年骨灰用户的真实评价)

pycharm 卡, 慢, 对 monorepo 中, 多 venv 切换支持烂. (远远不如 vscode) GPT 插件支持, 远远落后.

JB 几个语言的 IDE, 都已经开始免费了, 你就知道, 用户流失率有多高.

@tangc1986 #41 这个不错, 抽空试试. 感谢.

@Richared #47

老黄历了. 2025 了, 更新一下认知.

vscode 插件配置完备, 代码跳转 和 搜索能力, 并不比 jb 弱, 部分语言的 LSP 甚至更优.

JB 打开 monorepo 大项目, 一创建工程索引, 就炸机飙 CPU. (机器体验, M1 MAX + 32G, 也别提醒我改 vm 设置)

=============================================

vscode 比 jb 弱的是 大项目内 代码重构(函数重命名)能力, vscode 会有遗漏.

(也不是大问题, 静态语言, 编译报错, 就能发现. 动态语言, 大项目, 就别用这个操作)

JB 唯 2 还占优的功能: git 合并冲突 和 代码重构 & 重命名.

别的? 真没剩下啥了.

@jiyan5 #43

确实是 pylance(Pyright) 插件的作用.

vscode 禁用 pylance + 重启, 确实不能识别 相对路径导入的模块.

另外, 顺着你的提示, 发现 pylance 是基于 Pyright 的.

trae 可以安装 Pyright 插件, 安装了 Pyright, 就支持识别 相对路径的导入模块的识别了.

😄

@wryyyyyyyyyyyy #31

补充一下, 完整的 docker 构建 + 发布到 github (ghcr.io) 的脚本在这里:

https://github.com/better-sre/config/blob/main/dockerfile/_debian/Taskfile.yml#L34

这个是 debian 的发布脚本, ubuntu 的, 在对应目录下, 也都有.

每个目录的 readme.md 下, 有 Taskfile.yml 构建脚本的使用说明. 应该能看得懂.

注意需要配置 github token, 然后设置到 env 环境变量里.

具体我这个 repo 根目录, 有 .env.local 的参数格式. 可以看一下.

应该就这些了.

@wryyyyyyyyyyyy #31


你是指 docker 构建+部署吗? 具体参考如下内容.

这是我的基镜像 dockerfile, 包括 ubuntu22 和 debian12 的配置:

https://github.com/better-sre/config/tree/main/dockerfile

根据这个配置, 可以本地编译+发布, 也可以利用 github action, 我懒得写配置. 直接本地发布的.

这是我打包+发布到 github 的 docker 基镜像路径:

https://github.com/orgs/better-sre/packages


南京大学对 github docker 源 ghcr.io 的镜像:

https://sci.nju.edu.cn/9e/05/c30384a564741/page.htm

基于 南大的 mirror, 就可以在国内云主机, 快速拉到基镜像, 再在云主机上 docker build 就快了.

@wryyyyyyyyyyyy #29

你这个发现, 确实棒!

--mirror 和 nju 的源, 我也确实测试过. 不好使. 没想到 设置环境变量是好的. 可以.

我用国内主机使用 apt 安装 python + docker 构建好含对应 python 的基镜像 + mirror pull 方式, 绕过的.

这个 https://python-standalone.org/#/ 是谁部署的? 不太敢用?

docker 基镜像, 使用 github 托管, nju 对 github docker 做了镜像. 挺好用.

vscode 优点:

1. GPT 体验最好. pycharm 远远跟不上趟.

2. Python, Go, Rust, 前端, 等开发体验, 相当好. (还有多少市场留给 Jetbrains?)

3. Python 上, 对 monorepo 中多 venv 切换支持, 体验吊打 Pycharm.

4. 插件丰富. 让我认真想一想 Pycharm, Goland, Clion 等独有更好的插件, 想不出多少有比较优势的. 毕竟不是 10 年前.

时代真是变天了.

vscode 缺点:

1. 插件优化水平参差不齐. 拿 GPT 插件, 国内一众, 很多性能优化很烂, 很吃 内存 + CPU.

M1 MAX + 32G 的机器, 经常性 抽风 CPU 飙满. 搞的我把某阿里的 GPT 插件给 ban 了. 只用免费的 codegeex 做代码补全.

2. 想不出太值得讲的缺点. 除了上面的插件性能烂 + 大项目, 导致的 vscode 卡死 + 重启, 甚至还有个 专门重启的插件挺好用. 😓 (这个问题好解决, 就是把 垃圾插件卸载, 比如 阿里的 GPT 插件.)

我目前是头条的 Trae + vscode 搭配用, Trae 主写代码, 主要是白嫖一个免费补全能力. 偶尔切 vscode.

对于 GPT chat, 作为低频用户, 不是很 care.

(关于 Trae 能力, 部分不如 vscode, 拿 python 举例, Trae 不支持 相对路径导入包的模块, 识别+解析+跳转. 而 vscode 就支持. 就很搞笑. 本体 vscode 有的能力, 山寨货, 还能二次阉割的? 迷惑.)

而 pycharm, goland, clion, 早已经卸载.

JB 上唯一还闪光的点, 可能只剩下 git 合并冲突的能力. 笑.

(开源伟大, 曾经 JB 独享的功能, vscode 也基本都有了, 甚至体验更佳)

uv 目前在国内云主机使用上, 唯一的不方便是使用 uv 安装 python.

(其他基本都完美, 支持 workspace 模式, 非常爽)

比如 uv install python3.12, 会走官方源, 被墙(梯子问题). mirror 通常只是镜像了 pypi 的包, 而不包含 python 本体.

(当然, uv 支持使用 os 安装的 python 版本来创建 venv 环境, 也能绕过, 虽然不够方便. so, 你可以使用 apt 安装 python)

在云主机上, 裸构建 docker image + python 时, 略不变.

(同样, 可以在网络通的环境, 打包好. 再 mirror 过去, 拉成品 docker image, 也可绕过.)

总体就这些小不便, 其他体验都很完美.

另外, vscode 对 uv + venv 支持非常完美, 甚至好过 pycharm.

(pycharm 对 monorepo 的多 venv 管理 + 切换体验, 简直狗屎)

作为 pycharm 骨灰级用户, 弃用 pycharm, 改用 vscode.

2 个核心原因: GPT 体验 + UV 体验, vscode 都要吊打 pycharm.

1. 非 conda 生态, 一律首选 uv(rye 已废弃, 合并到 uv).

2. conda 生态, 推荐 pixi. (混编, 支持安装 py, cpp, rust 等多语言包, 实现统一管理)

https://pixi.sh/latest/

3. 顺便 Mojo(Python++) 也是使用 pixi 来做包管理工具.

uv 和 pixi 都是基于 rust 开发的, 设计理念很接近, 都借鉴了 cargo 的设计理念, 很现代.

其他过去常用的 pyenv, pip, poetry, pdm 等等, 都不建议, 也不需要使用了. (uv 完备, 其他大都是残疾人.)

我的 M1 MAX Mac + macOS 14.6, Type-C 直连 40 寸 显示器, 也会出现这个问题.

巧的是, 这个显示器的面板, 同样是 LG 的.

另外一台 28 寸 4k 优派的显示器, 就没有这个问题. (有相反的问题, 那一台, 经常是长时间睡眠 + 无法唤醒, 要重新开关电源)

这个 外键显示器睡眠问题, 真的是有毒. (10 年如一日的讨论, 依然没有有效的解决方案)

目前这台, 基本上是每天大半夜, 时不时的点亮, 再熄灭. (开始我以为是有啥 电子设备 干扰)

优点是: 这个显示器, 从睡眠中, 唤醒贼快. 随便敲一下键盘, 就唤醒了.

(之前那台 28 寸, 唤醒要 10 多秒)

这真是鱼和熊掌问题.

@lijie33402 #48

官方提供多个 arkui-x 的 demo, 包括多页面, 日常的 电商, 新闻类 App 的模板页的示例.

我编译 + 安装到 Android 手机, 实测效果, 体验挺流畅.

我并没有用 arkui-x 开发比较大的 App, 无法给你一手体验.


不过, 这算华为主推的跨平台解决方案, 原因:

1. 华为也要适配自己老的 Android 设备, 跨平台是自身刚需.

2. 吸引其他平台的 App 能够更多迁移到 鸿蒙 next 上, 有足够的动机, 来兼容其他平台.

3. 新增 app 开发, 不会有开发者会为了他一个平台, 单独搞一套.(市场份额决定)


综上推理, 可以分析, arkui-x 不会是个 KPI 方案, 反而是决定能否吸引到开发者的决定成败的方案.

我个人不认为是 PPT 方案. (官方文档非常详细)

一家之言, 仅供参考.

如果是从 0 到 1 的新项目, 可以尝鲜.

@daya0576 #23

如果是基于 NiceGUI 方案, 应该无法编译成 iOS/Android 应用.

如果你只熟悉 python, 可以看看 flet 方案( python + flutter 混合方案)

https://flet.dev/

但是 flet 方案, 我实测效果, 也很一般


https://github.com/better-py/learn-py/tree/main/packages/py-gui

这里有基于 flet 写的示例 demo.

如果你使用过 flutter 做开发, 可以考虑. 否则, 不建议使用. (可能搞不好开发环境)

python + mobile 开发, 没有良好方案, 包括 kivy, 都有各自的缺陷.


顺便, 如果你不局限于 python, 可以考虑 Tauri(rust+前端), 这个已经支持编译到 iOS 和 Android.

使用 Tauri, 你可以搭配 Vue.js + Quasar.js (NiceGUI 就是基于 Quasar). 来写.

顺便现在有 DeepSeek R1, 写 Rust 的难度, 大大降低, 报错就直接丢给 R1 来修.

这个算是比较正经点的方案.

顺便, 这里有个 tauri 的示例. (注意 tauri 2.0 已经支持 mobile app)

https://github.com/better-rs/learn-rs/tree/main/crates/rs-tauri-vue

https://tauri.app/

这个 demo 没更新 tauri 版本.

@skymanv2 #43

新增一个方案 flet:

https://github.com/flet-dev/flet


我是在使用多个方案: Tauri, Flet, ArkTS+ArkUI-X, Kotlin.

根据具体场景, 选择适合的方案.

Tauri: 嫖 rust + js 库时使用. 搭配 vue.js 快速糊 GUI 小工具.

Flet: = Python+Flutter. 单纯的 Flutter 不建议使用, 没有太大优势. 但是 flet, 可以用. 这个是白嫖 flutter 的绘图能力, 100% python 代码写应用. 利用 flutter 的能力, 糊个漂亮的 gui 还是很轻松的. python 库也最多, 最方便.

ArkTS: 技术储备, 为华为鸿蒙开发原生应用首选. 配合 ArkUI-X 跨平台能力也是完备的. 本身大量"借鉴/抄" flutter + kotlin 等特性, 熟悉 flutter, 上手也很快.


Kotlin: 备胎方案, 以上方案不满足的时候, 考虑. (本身跨平台能力也完备, 至少 Desktop 生态比较弱)

我比较关注的方案:

1. Tauri 2.0, 支持 desktop(macOS, Windows, Linux) + mobile （ iOS, Android) 跨平台， 偏前端方案。

2. 鸿蒙 ArkTS + ArkUI + ArkUI-X(跨平台），支持 moible （ iOS, Android, 鸿蒙 5.0 ），偏前端方案。

3. Kotlin + Kotlin Multiplatform(KMP + KMM)，支持 desktop + mobile 跨平台，能力完备，偏原生方案。

4. C# + Unity ， 支持 mobile （ iOS, Android), 偏游戏开发，不适合常规 app UI 交互。

-------------------------------------------------------------------------------------------

不推荐的方案：

1. Flutter ，相比上述方案，有明显短板.(原因很多，不赘述，flutter 是我唯一觉得投资失败的技术栈, 收益极低）

2. Electron ，有争议，用的人很多，但我个人不喜欢。（ Tauri 解决不了的，换其他，我也不用)

2. Qt 类（ PyQt 等），跨端的平台多，开发效率和兼容性，都跟不上，能接受 qt ，大概可以看看 Kotlin 方案。

3. 其他未提到的: React Native, Wails(go+js), NiceGui(python+js).

-------------------------------------------------------------------------------------------

技术方案投资，关注点 & 指标：

1. 好爹（爹不行，后继乏力，爹不靠谱，不兼容升级太多，都别用）

2. 技术品味 & 技术先进性（性能合格，开发效率够高，易于复用 & 易于迁移 or 移植他领域）

3. 符合市场发展趋势（注意是市场， 市场， 市场！）

4. 生态完备度（插件库够多，易于移植/白嫖其他生态，易于造轮子）

-------------------------------------------------------------------------------------------

拿这些指标，反复检验如上技术栈，评估符合自己需求的技术，做技术投资 & 技术储备。

选对方向，早做投资，早吃红利。

初步判定可能是某个 AI 插件导致的。

禁用了该插件之后，暂时没再 crash 。