uo4 技术教程组

想做个小工具，光搭后端就要花两天：起数据库、配鉴权、搞文件存储、再做个管理界面。业务代码还没写，人已经累了。 PocketBase 把这些打包进 一个二进制文件 ：下载、执行，后端就好了。 小项目的后端困境 一个最小可用的后端通常要凑齐这些： 数据库（MySQL / PostgreSQL） 用户认证...

收藏夹里躺着几百个链接，一篇都没看。想读的时候点开，发现页面已经 404 了。 浏览器收藏夹只存了一个地址， 不存内容 。wallabag 存的是文章本身。 收藏夹为什么不管用 问题不在于你懒，在于工具的能力就到那了： 只存链接，不存内容 — 原网页一变，你就什么都没了 不能离线读 — 地铁上、飞机...

算法推荐越推越窄：你点过什么，它就一直给你什么。真正想看的更新，反而刷不到了。 RSS 是个老技术，但它解决的问题没变—— 让我自己决定看什么 。FreshRSS 就是一个能自己部署的 RSS 阅读器。 算法信息流的三个问题 第一，排序权不在你手上。 内容按"你可能喜欢"排，而不是按时间或你的订阅顺...

想在产品里问用户几个问题，用第三方问卷工具的话，数据先落到对方服务器上，想嵌进自己产品还得套个 iframe。 Formbricks 是一个可以自己部署的问卷与体验管理工具， 数据进自己的库，问卷也能原生嵌在应用里 。 第三方问卷的隐性代价 常见的麻烦有这几类： 数据归属 ：收集到的用户反馈存在平台...

客户从网站来、从邮件来、从社交媒体来。于是客服同时在三个后台里回消息，同一个人的对话被切成三段。 Chatwoot 做的是把这些渠道 收进一个收件箱 ，而且可以部署在自己的服务器上。 多渠道带来的割裂 渠道增加的时候，问题不是"消息变多了"，而是 上下文断了 ： 客户先在网页问，后又发邮件，客服不知...

CRM 有个很不友好的定价特点： 按人头收费 。团队刚起步时便宜，人一多账单就上来了。 Twenty 是一个可以自己部署的开源 CRM，把客户、商机、跟进任务收在一处， 数据放在自己服务器上 。 小团队的 CRM 困境 不用 CRM 的团队，客户信息通常是这样的： 线索散在邮箱、聊天记录、Excel...

每个公司都有一堆"排不上期但天天在用"的内部工具：查订单的、改配置的、看数据的。 它们不复杂，但正经开发要走一遍需求、设计、前端、联调，一做就是一周。Appsmith 把这个周期压到 一个下午 。 内部工具的尴尬处境 这类需求的共同特点： 用户量小，就内部几十个人 逻辑不复杂，基本是查和改 但界面、...

业务同学想改一条数据，你说"我写个 SQL"；他们说想看个表，你导出一份 Excel 发过去。然后他们改完再发回来，你再导进去。 NocoDB 的做法是： 别搬数据，给现有数据库套一层表格界面。 研发和业务之间那道墙 数据存在 MySQL / PostgreSQL 里，但能用它的人只有会写 SQL ...

想看看自己网站的访问量，结果为了这一个需求，装了一套跨站跟踪脚本，还得配一个 Cookie 同意弹窗。 Umami 想说的是： 你需要的可能只是那几条曲线，不是那一整套数据采集体系。 统计工具的过度设计 主流分析工具功能确实强大，但对大部分网站来说，真正的需求其实很朴素： 有多少人来、看了几个页面 ...

设计数据库的时候，最烦的不是想不清楚表结构，而是 画完图之后还要手写一遍建表语句 。 图上加一个字段，SQL 里就得同步改一次，改来改去两边对不上，最后以哪个为准都说不清。 drawDB 把这两件事合并成了一件事。 图与 SQL 分离的老问题 传统做法通常是这样： 先用工具画图。 用绘图软件或者专业...

手机相册的免费额度总有用完的一天，而这时候你才发现： 照片传上去容易，想完整拿回来很难。 Immich 是这几年最受关注的自托管相册项目，目标很明确—— 把云相册的体验搬到自己机器上 。 云相册的两个隐性代价 第一是成本结构。 照片视频只会越存越多，容量是刚性消费，而且逐年上涨。 第二是数据主权。 ...

同步盘很方便，但有个前提你很少去想： 你的文件必须先传到别人的服务器上，才能同步到另一台设备。 Syncthing 把这个前提取消了。 中心化的隐形成本 用云同步盘，你实际上接受了几件事： 文件要上传到服务商服务器，隐私靠信任 容量要买，免费额度很快就满 同步速度受上行带宽限制，大文件要等 服务商改...