码厩开发者笔记

#1280 PostgreSQL 与 MySQL 的 JSON 类型：Go 项目怎么选

关系型数据库支持 JSON 已经很成熟，但 JSON 并不意味着可以随意替代普通字段。实际项目中，更重要的问题是：PostgreSQL 的 json 和 jsonb 怎么选？MySQL JSON 如何建立索引？Go 又应该怎样读写？

#1279 MySQL 和 PostgreSQL 时间戳的坑

同样叫 Timestamp，MySQL 和 PostgreSQL 的语义并不相同，也是跨库迁移和应用开发中最容易踩坑的地方。

#1278 中国劳务派遣制度的发展、争议与未来走向

中国劳务派遣制度本质上是市场经济发展过程中，为满足企业灵活用工需求而形成的一种特殊劳动用工形式。它并非中国独有，但在中国的发展路径具有明显的国企改革和劳动力市场转型特征。

中国现代意义上的劳务派遣最早可追溯至改革开放后的涉外劳务服务。20世纪80年代末至90年代，随着外资企业进入、劳动力市场逐步建立，劳务派遣开始出现并逐渐扩大。与此同时，国企进入“减员增效”和改制重组阶段，部分企业通过人员分流、调整劳动关系等方式降低传统用工模式的负担，劳务派遣也逐渐成为灵活用工的重要方式之一。因此，国有企业确实是中国劳务派遣早期的重要需求方和推动力量。

2008年，《劳动合同法》正式确立劳务派遣制度。但随着制度快速发展，一些企业开始利用劳务派遣规避正式用工责任，出现“同工不同酬”“假外包、真派遣”“长期派遣”等问题。

2012年，《劳动合同法》修订后进一步强化监管，明确劳务派遣应主要用于“临时性、辅助性、替代性”岗位。2014年实施的《劳务派遣暂行规定》又明确，用工单位使用被派遣劳动者的数量原则上不得超过其用工总量的10%。中国劳务派遣制度由此开始从快速扩张转向严格规范。

PS：现实中，很多企业将劳务派遣统称为“外包”，但两者并不相同。一些所谓外包员工虽然劳动合同签在第三方公司，却长期在甲方工作，接受甲方直接安排、考勤和管理，本质上仍属于劳务派遣。这种“假外包、真派遣”现象，也可能被用于规避派遣岗位和用工比例限制。

劳务派遣并非中国独有。日本、美国、德国、法国等国家都存在类似制度，日本甚至形成了规模庞大的派遣产业。但不同国家的监管模式存在明显差异，通常围绕派遣岗位、使用期限、工资待遇、社会保障以及实际用工责任进行规范。

因此，真正的问题并不是“是否应该存在劳务派遣”，而是劳务派遣是否被企业异化为长期压低人工成本、规避劳动责任的工具。如果派遣工长期承担企业核心业务，却在工资、福利、晋升和职业保障方面长期低于正式员工，那么劳务派遣实际上就可能形成新的劳动身份分层。

从社会主义发展目标来看，劳务派遣制度本身并不天然与社会主义相违背。社会主义市场经济同样需要劳动力合理流动，也需要企业根据经营变化进行灵活用工。问题的关键在于，市场效率不能以牺牲劳动者基本权益为代价。

如果大量企业将派遣工长期固定在核心岗位，并形成身份分层、待遇分层和保障分层，那么问题已经不再只是灵活用工，而是劳动权益分配失衡。这确实会与共同富裕、劳动者权益保护以及劳动价值应得到尊重的社会目标形成矛盾。

未来，中国劳务派遣制度大概率不会取消，而是继续收紧和规范。核心方向应该包括：严格限制派遣岗位范围，落实同工同酬原则，压实实际用工企业责任，提高违法成本，并防止劳务派遣成为企业的基础用工模式。

长期来看，劳务派遣应当回归临时性和补充性的定位，而不是成为企业长期替代正式劳动关系的工具。只有在企业灵活用工需求与劳动者权益保障之间建立合理平衡，劳务派遣制度才能真正服务于经济发展，而不是制造新的劳动不平等。

思考：为什么劳务派遣、年龄门槛、编外人员与正式编制身份分层、长期临时工等用工做法，在政府机关、国有企业和公共部门同样普遍？作为以社会主义和劳动者权益保护为重要价值目标的国家，政府及国有企业为何也会采取这些容易造成劳动身份和待遇差异的用工方式？

#1277 NGINX 1.31.5 Predicate Location：从按 URL 路由到按条件路由

#1276 为什么 Linux 有优秀工程师，却缺少优秀的桌面产品？

Linux 在服务器、云计算等领域无处不在，也拥有大量优秀工程师，但桌面产品长期难以与 Windows、macOS 竞争。问题未必是技术能力不足，而是：

1. Linux 缺少一个真正对完整产品体验负责的主体。

   Windows 有微软，macOS 有苹果。界面不好用、软件体验不统一，最终都有人负责。

   Linux 则涉及内核、桌面环境、发行版、软件包和大量社区成员，常常是每个组件都有人维护，但整个产品没人负责。

2. 开源社区擅长技术决策，却不一定擅长设计。

   技术问题可以讨论、测试甚至投票，但审美和产品体验往往需要取舍。优秀设计必须有人敢说：“这个功能不需要，这个设计不行。”

   但社区文化强调包容和尊重不同需求，结果容易形成“功能越来越多，默认体验却越来越平庸”的局面。

3. Linux 有时会把技术路线放在产品体验之前。

   一个软件是否适合作为默认应用，讨论的不只是好不好用，还可能涉及许可证、Mono、微软等技术路线争议。

这也是 Omarchy 这类“强主张软件”受到关注的原因。像 Omarchy，由 DHH 直接决定默认桌面、快捷键和软件组合。用户当然可以修改，但默认答案只有一个。

Linux 桌面真正的问题不是民主，而是责任被稀释。可以广泛讨论，但产品最终必须有人拍板。

设计不是投票。Linux 擅长给用户选择，却不擅长替用户做决定。而优秀的消费级产品，往往不是提供最多选择，而是在无数选择中，坚持做出一个足够好的默认答案。

以上观点，根据微信公众号文章《Ubuntu设计团队往事：品味是如何死在投票箱里的？》整理。

#1275 ESP: Resend

Resend 不是传统的企业邮箱服务，而是一个面向开发者的 Email Infrastructure 平台，定位类似 SendGrid、Mailgun、Amazon SES。

#1274 主流 LLM API 风格详解：Chat Completions、Messages 与 Responses

目前主流大模型 API 大致有三种风格：OpenAI 的 Chat Completions / Responses（新版本）和 Anthropic 的 Messages。

#1273 独立开发者 MVP 工具链

微信推送的两种图片中展示了一个“独立开发者穷鬼套餐（2026版）”，我让 GPT 重新给我整理了一个版本：

程序主要运行在 Serverless / Edge 环境，依赖的数据库、KV 等服务也基本都是白嫖。

#1272 Stalwart + Bulwart Webmail 搭建邮件系统

• Stalwart Mail Server
  https://github.com/stalwartlabs/stalwart
  All-in-one Mail & Collaboration server. Secure, scalable and fluent in every protocol (IMAP, JMAP, SMTP, CalDAV, CardDAV, WebDAV).

  Stalwart 是采用 Rust 开发的开源邮件与协作服务器，集成 SMTP、JMAP、IMAP、POP3、Sieve，以及 CalDAV、CardDAV、WebDAV 等协议，同时提供反垃圾邮件、反钓鱼、DKIM/SPF/DMARC/ARC、OIDC、2FA、Prometheus 等能力。它既可以单机运行，也支持进一步扩展到集群。

• Bulwark Webmail
  https://github.com/bulwarkmail/webmail
  Self-hosted JMAP webmail for Stalwart Mail Server. Mail, calendar, contacts, and files in one client.

  Bulwark 是面向 Stalwart 的现代化自托管 Webmail，基于 Next.js 开发，以 JMAP 作为主要通信协议。除了邮件，还提供日历、通讯录和文件管理，并支持 SSO/OIDC、2FA、多账号、全文搜索、Sieve、PWA 等功能。

方案

可以采用 Stalwart Mail Server 作为邮件系统核心服务，Bulwark Webmail 作为统一 Web 邮箱前端，构建一套轻量、现代化、可自主管理的企业邮件平台。

整体方案的主要价值是减少邮件系统组件数量，同时保持标准协议兼容性。对于个人邮件、企业内部邮箱、小型邮件服务平台以及需要自建 Webmail 的场景，这套组合值得优先进行 PoC。

部署层建议采用 Docker Compose + Nginx。
DNS 配置 MX、SPF、DKIM、DMARC、PTR/rDNS，并根据实际业务配置 SMTP 出站策略。

mail.example.com
├── :25   SMTP
├── :587  Submission
├── :143  IMAP
├── :4190 Sieve 邮件过滤规则管理
└── :443  HTTPS（Nginx）
           ├── Stalwart JMAP
           ├── Stalwart CalDAV
           ├── Stalwart CardDAV
           ├── Stalwart WebDAV
           └── Bulwark Webmail

存储方面，初期可采用单机部署，邮件数据、索引和附件使用本地磁盘（嵌入式 KV 数据库 RocksDB）。

可以通过 Docker 部署 https://hub.docker.com/r/stalwartlabs/stalwart，也可以直接在服务器上安装：

curl https://get.stalw.art/install.sh -o install.sh
sudo sh install.sh

• /usr/local/bin/stalwart
• /etc/stalwart/stalwart.env
• /etc/stalwart/config.json
• /var/lib/stalwart/ (数据)
• /var/log/stalwart/ (日志)

#1271 AI 时代程序员的未来

AI 写代码已经越来越强，但截至目前，并没有出现有些人预言的大规模程序员失业潮。美国 BLS 数据显示，2025 年软件开发者就业人数约 168.8 万，预测 2025—2035 年软件开发者就业仍预计增长约 10%。

原因并不复杂：AI降低的是软件开发成本，而不一定降低软件需求。 当一个功能从过去需要3个人做一个月，变成一个程序员借助AI几天完成，公司未必选择裁掉3个人，也可能选择同时开发更多功能、尝试更多产品、服务更多客户。过去因为“开发成本太高”而放弃的需求，现在可能都变得值得做。

真正值得警惕的是，AI正在改变程序员内部的就业结构。

斯坦福数字经济实验室 2026 年 8 月基于数百万名员工的 ADP 工资数据发现，整体就业尚未出现大规模 AI 替代，但 22—25 岁、处于 AI 高暴露职业的年轻人，就业水平已经比低暴露职业同龄人低约 19%；而有经验的劳动者没有出现类似幅度的缺口。软件开发者属于 AI 暴露程度最高的职业之一，其中 22—25 岁开发者下降尤其明显。

这意味着，AI首先冲击的可能不是35岁以上的老程序员，而是原本负责简单CRUD、改页面、接接口、补测试的初级岗位。

那么，新老程序员应该何去何从？

• 新人不能再把“会写代码”当成核心竞争力。 AI已经可以承担大量基础编码工作，新人的价值必须从“执行任务”转向“理解问题”：

  • 学习计算机基础、数据库、网络、操作系统、工程规范，
  • 同时利用AI快速完成实现，并通过真实项目积累业务经验。

• 老程序员也不能躺在经验上。 AI确实放大了经验的价值，但前提是你能够驾驭AI。

  • 未来更值钱的能力，是架构设计、复杂系统排障、业务理解、技术决策、风险控制，
  • 以及把模糊需求转化成可靠系统的能力。

所以，AI时代真正危险的不是“老程序员”，也不是“年轻程序员”，而是只会写代码、却不知道为什么写，以及不会利用AI提高生产力的人。

三年前大家问的是“AI什么时候替代程序员”。现在更应该问的是：当代码越来越便宜之后，你还能解决什么过去解决不了的问题？这才是新老程序员真正需要回答的问题。