企业官网建设流程全解析

说实话，市面上叫“待办清单”的App我前前后后试过十几个，从手机自带备忘录到各种云同步神器，没有一个能让我坚持超过一个月。要么功能太散，番茄钟是一个App、任务管理是另一个App、时间统计又要单独装，数据还东一份西一份；要么就是免费版阉割严重，想要个稍好用的功能就得开年费订阅。直到我接触到super-productivity这个开源项目，才第一次体会到什么叫“工具追着人跑”。它把待办任务、番茄钟、时间追踪、任务统计全揉进了同一个界面，支持吃自己的资源做纯自托管部署，一条Docker命令就能把整套系统跑起来，数据完全不用交给任何第三方。这篇就聊聊它的核心功能、为什么值得自托管，以及从零到一的一键部署实操和踩坑记录。

1. 先搞清楚：super-productivity到底是什么

1.1 它不是又一个待办清单，而是一套时间管理闭环

很多人看到“待办任务”四个字就下意识觉得，这不就是TodoList嘛，我用系统备忘录就够了。但super-productivity的设计逻辑和普通待办App完全不一样：它默认把“计划—执行—回顾”串成了一条线。你在里面建一个任务，不是打个勾就算完，而是可以给这个任务绑定一个番茄钟，点开计时器干活，干完这轮番茄，App自动记录你在这个任务上花了多少时间；任务完成后，后台的统计面板会告诉你今天、本周在哪个项目上投入了多少分钟，完成了多少项任务。

这个闭环的价值在于，它把“时间管理”从一句口号变成了可量化的数据。普通待办App只会问你“做完了没有”，super-productivity会额外问你“做了多久”“什么时候做的”“这类任务吃掉了你多少时间”。这些数据积累下来，就是你自己最真实的时间账单。我用了大概两周之后，第一次看清自己每天真正高效工作的时间段，以及哪类任务在偷偷消耗我的精力，这比任何效率鸡汤都管用。

1.2 核心功能一览

我把比较常用的功能模块整理一下，方便你对照自己的需求：

• 任务管理：支持任务分组、子任务、标签、优先级、到期日期、定时提醒，还能给任务追加备注和附件信息。
• 番茄钟：内置番茄工作法计时器，和任务直接关联，做完一轮自动记录，可以自定义专注时长和休息时长。
• 时间追踪：支持手动计时和自动计时两种模式，每个任务、每个项目单独累计，随时查看当日/当周投入。
• 数据统计：按天、周、月维度，统计完成任务数、累计专注时长、各项目/标签的时间分布，这部分对复盘特别有用。
• 外部集成：可以连接GitHub、GitLab、Jira的Issue，把开发任务直接拉进待办列表，工单进度一目了然。
• 多端同步：通过WebDAV或CalDAV协议同步数据，也可以配合官方后端服务实现客户端之间的数据互通。
• 快捷操作：全键盘流操作，热键新建任务、切换项目、启动番茄钟，干起活来不用离开键盘。

对于开发者来说，GitHub和Jira集成是很大的加分项；对于普通上班族和学生党，番茄钟加统计面板才是每天真正离不开的功能。

1.3 适合谁用，不适合谁用

先泼一盆冷水：如果你只是想要一个“把事记下来别忘”的轻量工具，super-productivity的开箱成本对你来说可能偏高了。它适合的，是那些愿意花点时间把任务系统搭起来、并且希望通过数据复盘来改进工作节奏的人。程序员、项目经理、自由职业者、备考学生，这几类人群和它的匹配度最高。

同样是自托管待办工具，它和Vikunja这类强调“多人协作看板”的项目不同，super-productivity更偏向个人深度使用，强调的是“一个人如何把一天过得更清楚”。所以如果你是团队协作场景，应该去看别的方案；如果是给自己搭建一套个人时间管理系统，那它就是目前开源生态里非常能打的一个。

2. 为什么值得自托管：我的选型思路

2.1 数据握在自己手里，心里才踏实

我选自托管工具的第一理由永远是数据所有权。待办清单这东西看着不起眼，但里面存的是你整个生活和工作安排：什么时间干什么事、哪些项目在推进、每天时间花在了哪。把这些数据放在别人的云服务器上，等于把日程透明化成给第三方看。有时候也不是信不过厂商，而是你永远不知道哪天服务调整、账号异常或产品下线，数据说没就没。

super-productivity本身是开源项目，代码完全公开，部署之后跑在自己的服务器或家里的NAS上，浏览器访问、数据落在自己控制的范围里。哪怕有一天项目停止维护，只要部署文件和数据文件还在，你的系统依然照常运行，这种安全感是商业SaaS给不了的。从投入产出比看，一次部署半小时搞定，换来的却是长期的数据主导权。

2.2 开源可扩展，不受产品路线绑架

商业待办工具最大的问题不是收费，而是它的功能走向你说了不算。今天给你加个AI总结，明天改版把顺手的功能藏到付费墙后面，你只能被迫适应。开源项目就不存在这个烦恼：想要的功能可以提Issue，着急就自己改代码，或者干脆用别人贡献的插件和第三方客户端。

super-productivity的架构也比较良心，前端是Web应用，部署灵活。你可以只跑一个静态页面，也可以搭配官方后端服务实现账号同步；桌面端还有Electron打包的客户端，Windows、macOS、Linux都覆盖。底层用Angular开发，成熟稳定，社区虽然不算大，但Issue响应积极，版本迭代一直没停过。

2.3 和主流工具的横向对比

拿sheet风格做一个直观对比，不吹不黑：

看完这个表你应该明白我的意思：super-productivity不是“功能最多的待办工具”，而是“功能整合度最高且数据可控的待办工具”。它把好几类工具的能力集中在一个界面里，省去了我在多个App之间切换的摩擦。

3. 一键部署实操：从零跑起来

3.1 部署前的环境准备

super-productivity的部署方式很友好，本质上就是一个容器化的Web应用。我推荐用Docker Compose来跑，理由有三：配置文件一目了然，后期迁移直接复制目录就行，升级时改个镜像版本号重拉即可。

先说前置条件。你需要一台能长期运行的机器，可以是云服务器、家里的NAS，或者吃灰的小主机，配置要求很低，1核1G跑它都绰绰有余，毕竟它主要是个前端应用加轻量后端。系统装好Docker和Docker Compose插件就行。如果你用的是群晖这类NAS，在套件中心装好Container Manager，原理一样。域名不是必须的，直接用IP加端口访问也能用，但如果你打算认真长期使用，我建议后面套一层反向代理，配上HTTPS，这样即使在外网访问也安全。

3.2 Docker Compose 部署配置

这里贴一份我实测可用的compose配置，核心就两个服务：一个是Web前端，负责提供页面和主要功能；另一个是可选的服务端，用于注册账号、多设备同步数据。如果你只有一台设备使用，不跑服务端也行，但既然要“一键部署”，我建议一步到位，把同步能力也放进去。

version: "3" services: super-productivity: image: ghcr.io/johannesjo/super-productivity:latest container_name: super-productivity restart: unless-stopped ports: - "8080:80" volumes: - ./data:/data super-productivity-server: image: ghcr.io/johannesjo/super-productivity-server:latest container_name: super-productivity-server restart: unless-stopped environment: - PORT=3211 - DATA_DIR=/data ports: - "3211:3211" volumes: - ./server-data:/data depends_on: - super-productivity

说几个关键点的考量。端口映射这里，我把前端的8080映射到了容器内的80端口，因为官方镜像默认用Nginx伺服静态页面，后端服务端口习惯用3211。如果你本机8080端口已经被占用，换个宿主侧端口就行，比如8081：80。restart: unless-stopped是让容器在机器重启后自动拉起，这是“长期服役”必备配置。数据目录挂载出来是为了升级容器时不丢数据，这个一定要做，不然哪天删容器重建，数据全没了。

配置完成后，在目录下执行：

docker compose up -d

第一次启动会拉镜像，网络正常的话一两分钟就能完成。看到两个容器状态都是Up之后，浏览器访问http://你的服务器IP:8080，就能看到登录和设置页面。所谓一键部署，到这一步就算跑通了。我这种yolo型选手最喜欢的玩法就是先拿现成脚本一把梭跑起来，细节后面再慢慢调。

3.3 前端、后端连接与初始化

页面能打开只是第一步，要把前后端串起来，还需要在页面的配置里指定后端服务地址。进入设置，找到同步或服务端相关选项，填入http://你的服务器IP:3211。这里有个我在部署时踩过的坑：如果你在服务器本机上访问页面，填localhost:3211没问题；但如果是从局域网内另一台电脑访问页面，千万别填localhost，要填服务器的局域网IP，不然浏览器里的前端脚本根本连不上后端服务，同步怎么配都不成功。

后端服务初始化好账号之后，前端会要求你登录。登录成功就完成了同步通道的打通。这里要提醒一下：前端的核心数据其实是存在浏览器本地的，后端的作用更像是同步枢纽，帮你把多台设备的数据汇总起来。理解了这一点，后面遇到“为什么这台设备改了，另一台没变”的问题时，思路就清晰了。

3.4 数据持久化与备份方案

自托管最忌讳的就是“数据裸奔”。我见过太多人部署完就撒手不管，结果一次容器重建悔得肠子都青了。super-productivity的数据分两部分：一是浏览器本地存储，这个没法在服务器上直接备份，只能靠同步机制把数据捞到服务端副本；二是服务端的数据库文件，就在我们挂载出来的./server-data目录里。

所以我的备份策略很简单也很稳：定期把server-data目录打包下载，或者写个cron脚本每天压缩一份存到另外的位置。恢复时只需把目录放回原位，重建容器即可。前端静态页面本身没有需要备份的数据，它就是个壳，真正的心血都在同步服务端。加上这个目录本身很小，备份成本几乎可以忽略，但关键时候能救命。

4. 上手使用：把时间管理玩明白

4.1 我的日常使用工作流

部署完成只是开始，真正让工具发挥价值的是使用习惯。我在实际使用中摸索出一套适合自己的工作流，写出来给你参考。每天早上的第一件事，不是打开邮件，而是打开super-productivity把今天要做的事过一遍：按项目归类，给每项任务估计一个番茄钟数，标注优先级，然后把最困难的那件事放在上午专注时段。

开始干活时，点开任务对应的番茄钟按钮，进入全屏专注模式，这期间不碰手机、不切网页，直到铃声响起。短暂休息后再来一轮。一个上午通常能完成三到四个番茄钟，下午再处理低脑力消耗的任务，比如回复消息、整理文档。晚上收工前，打开统计面板看一眼当天的数据分布，哪些任务预估时间偏差大，第二天调整计划时心里有数。这套流程坚持下来，我发现自己的有效工作时间其实并没有变多，但产出质量明显提升，因为每一分钟都清楚“现在该做什么”。

4.2 和GitHub/Jira等外部任务的联动

如果你是开发者，super-productivity的集成功能是你一定要尝试的。它支持把GitHub、GitLab上的Issue自动拉取到任务列表里，每个Issue对应一个任务卡片，状态变更和时间追踪都能关联上。我现在的做法是，把分配给我的Issue全部同步进来，再和手动创建的个人任务混排在同一个看板里，这样不会出现“工作系统一个待办列表、个人计划另一个待办列表”的割裂感。

Jira集成对项目经理同样实用，可以直接把研发工单拉下来跟踪进度。配置集成时需要在对应的平台里生成一个Access Token，权限按最小化原则来给，只开放读取Issue相关权限即可。Token不要硬编码在页面里，建议走环境变量或密钥管理。这块我从踩坑中得到的教训是：不要在浏览器里直接输Token，清缓存的时候容易一起清掉，安全上也不够讲究。

4.3 用统计数据做个人复盘

统计是super-productivity最容易被人忽视但其实最值钱的部分。它会把你的所有操作沉淀成图表，包括每天完成的任务量、每个项目的累计用时、不同标签下的时间分布。我每周末会花十分钟做一次复盘，重点看三个指标：本周总番茄数、任务完成率、时间花费Top3的项目。

不看不知道，一看吓一跳。有一段时间我总觉得自己忙得够呛，但统计数据告诉我，每周真正投入核心项目的时间只有不到12个小时，剩下的时间都被会议、临时插队的事和碎片杂务吃掉了。后来我根据这个数据调整了安排，每天上午固定两小时雷打不动的深度工作时间，会议尽量集中到下午，临时消息统一时间处理。节奏调整之后，周产出明显上升。这种基于真实数据的复盘，比任何“时间管理大师”的口头建议都更有说服力，因为它针对的是你自己的实际情况。

5. 踩坑实录与常见问题排查

5.1 部署与使用问题速查表

我用这种东西有个习惯，遇到问题当场记录，方便以后速查。下面这张表是我自己在部署和使用super-productivity过程中碰到的典型问题和对应的处理办法：

这里重点说一下同步冲突，这是多设备使用最头疼的问题。super-productivity的同步机制不是实时的多人协同，更像“多端写入，事后合并”。如果你在手机和电脑上同时改同一个任务，就可能出现版本冲突。我习惯的做法是，白天在主力设备上集中操作，另一台设备主要用来看和记录临时想法，避免同时编辑同一批任务，冲突概率能降到很低。

5.2 反代与HTTPS配置心得

用IP加端口访问很容易被浏览器安全策略各种限制，比如某些浏览器对非安全上下文里的本地存储和摄像头等特性有限制。所以我建议，一旦部署稳定，尽快配一个反向代理。Nginx配置大概这样写：

server { listen 443 ssl; server_name todo.example.com; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }

把todo.example.com换成你自己的域名，SSL证书用Let's Encrypt自动申请即可。如果你有后端服务需要走反代，记得给/api/之类的路径单独加一条location转发到3211端口。我这边的教训是，反代配置里务必要带上X-Forwarded-Proto头，不然前端无法正确判断请求是HTTPS，偶尔会导致一些安全和路径判断上的诡异问题。

5.3 升级与迁移实战

自托管应用绕不开升级这件事。super-productivity更新频率不低，新版本往往包含性能优化和功能修复。我的升级流程很简单：先备份server-data目录，然后执行docker compose pull拉取最新镜像，再docker compose up -d重建容器。整个过程一般五分钟以内，前端页面会短暂中断，但不影响后端数据。

迁移到新机器时更简单，把整个部署目录（compose文件加数据目录）拷贝过去，在新机器上执行同样的docker compose up -d，改一下新机器的IP配置即可。我实际迁移过一次，连浏览器端的重新登录都不用，服务端数据恢复之后，所有任务、项目、历史统计都回来了。这也是采用Docker部署最大的红利：环境一致性让运维复杂度直线下降。

5.4 关于坚持使用的一点建议

最后想聊聊工具的长期使用。很多人部署了各种效率工具，新鲜劲儿一过就扔在一边，转头又去收藏下一个“神器”。我在实际使用中的体会是，super-productivity这类自托管工具的初始门槛，恰恰帮使用者建立了一种仪式感：你为它付出了部署、配置、调优的成本，自然会更认真地使用它。

但仪式感是次要的，真正能留住我的是它的“低摩擦设计”。任务入口在首页正中央，快捷键全局可用，番茄钟启动只要两次按键，统计数据打开即见，不需要任何操作引导。当工具顺手到不需要思考怎么用的时候，坚持就成了自然而然的事。如果你也准备入坑，我的建议是从小处开始，先只建一个项目、每天记录两三个任务，跑通流程之后再逐步加功能，让这套系统长成你自己习惯的形状。