企业官网建设流程全解析

说起待办工具，我桌面上的图标真的是换了一茬又一茬，从手机自带备忘录到各种云端任务软件，最后发现能让我坚持用下来的，反而是这款开源项目super-productivity。它最大的特点就俩字：自由。任务、项目、番茄钟、日历、时间统计全塞进一个网页应用里，数据默认存在你自己把控的地方，隐私性拉满。更关键的是，部署门槛低到离谱，一条命令就能完成一键部署，跑起来之后每天打开就是“时间管理大师”的工作台。这篇文就聊聊我实际部署和日常使用的经验，包括它解决什么问题、怎么把服务拉起来、有哪些坑必须提前避开。不管你是上班族、独立开发者还是学生党，这套玩法都能直接抄作业。

1. 为什么是super-productivity：本地优先的时间管理全家桶

1.1 普通待办工具的痛点，它到底戳在哪

先讲个扎心的事实：大多数待办App用一阵子就吃灰，不是因为我们懒，而是工具本身割裂。你想想，待办事项在一个App里，番茄钟在另一个App里，时间统计在第三个App里，日历又是第四个。每天光在不同应用之间来回切换，就已经消耗掉大半的“行动力”。我以前的真实状态是：列了一堆任务，但没有一个地方能告诉我“今天到底干了啥”，到了晚上复盘，脑子一片空白。

super-productivity解决的就是这个割裂问题。它不是简单的todolist，而是把任务管理、项目分区、番茄钟、日历、时间段统计整合成一个连贯的工作流。你新建一个任务，标上预计耗时，然后在任务上直接启动番茄钟，时间一到应用自动记录实际花费。晚上打开统计面板，今天在哪些项目上投入了多少分钟，一目了然。这种“计划—执行—反馈”的闭环，才是时间管理能坚持下去的根本原因。

另一个我特别看重的点是本地优先。传统云待办工具，数据都存在人家的服务器上，哪天服务商调整策略或者跑路，你的历史记录就没了。super-productivity是开源项目，你完全可以把网页版部署在自己家里的老电脑、NAS或者一台云主机上，想什么时候访问就什么时候访问。即使离线状态，数据也先落在浏览器本地，运行速度飞快，不用等服务器响应。

1.2 全家桶里的核心模块：任务、番茄钟、日历与集成

如果你第一次打开super-productivity，可能会被左侧栏的一堆菜单吓到。但别慌，这些模块其实就是一个完整的时间管理闭环。我按日常使用频率帮你理一理：

• 任务与待办：这是地基功能。支持建任务、子任务、标签、优先级、预计耗时、实际耗时，还能直接拖拽排序。任务可以放进不同的“项目”里，相当于给你的工作分成了几个独立空间，比如“工作日”“个人学习”“家庭琐事”。
• 番茄钟：内置的Pomodoro计时器，跟任务深度绑定。选一个任务，点一下开始，自动进入25分钟专注倒计时，期间到点会提醒你休息。所有专注时间都会回写到任务的实际耗时里。
• 日历视图：把你安排的任务按日期铺开，可以按天、周、月查看。这里的量级不是“事件提醒”，而是“时间块”，方便你提前规划一天的时间预算。
• 时间统计：系统自动汇总每天、每周、每月的专注数据和任务完成情况。这是我最依赖的模块，周末回看一下，就能知道精力到底花在了哪儿。
• 外部集成：如果你在团队里用Jira、GitHub、GitLab，或者企业微信、Slack这类工具，super-productivity可以直连拉取issue和工单，把团队任务和个人任务统一到一个面板里管理。

这些模块单拎出来任何一个都不稀奇，但它们组合在一起，并且支持自部署，那就很少见了。很多商业工具把这套组合拳做成了订阅制，一年几百块起步，开源世界里能免费自托管的方案里，super-productivity绝对算第一梯队。

2. 部署前准备：硬件选型和一键部署方案对比

2.1 设备怎么选：老电脑、NAS还是云主机

在动手部署之前，先想清楚一个事：你打算把服务跑在哪。super-productivity的Web版本质上是一个静态前端应用，对性能要求很低，CPU和内存占用都极小，所以设备选择的灵活性很高。

• 树莓派或老笔记本：如果你手头有闲置设备，装个Docker跑它就非常合适。一台树莓派4B即使同时跑着Home Assistant、AdGuard，再塞一个super-productivity也绰绰有余。
• NAS：群晖、威联通这类NAS基本都自带Docker套件，在图形界面里新建容器即可。家里有NAS的朋友走这条路最省心。
• 云主机：如果你没有常开的本地设备，买个最便宜的云主机也能跑得很欢快。反正应用本身不吃资源，1核1G的配置都嫌多。

我自己的方案是放在一台旧NUC上，系统是Ubuntu，装好Docker之后常年不关机。实测下来运行大半年，内存占用始终保持在150MB上下，待机功耗几乎可以忽略。需要注意的是，无论选择哪种设备，尽量保证它7x24小时在线，因为待办工具这东西“随时能打开”比“功能多”更重要，你不想早上到公司发现家里NAS断电了。

2.2 部署方案选型：Docker Compose为什么更省心

部署super-productivity主要有两条路线。一条是官方仓库里提供的一键部署脚本install.sh，本质上是拉取镜像然后映射端口跑容器。另一条是写docker-compose.yml来管理。两种方式我都试过，这里说说我的结论。

官方脚本更适合尝鲜。执行一行命令，脚本自动帮你拉镜像、起容器、配置端口，几分钟后浏览器就能打开。但问题也很明显：所有参数都写死在脚本里，想改端口要重新跑一遍，后续想升级或者查看容器状态，还得额外记忆不少命令。对“装完就不想动”的人来说，体验不错；但如果你想长期稳定用，我个人更推荐Docker Compose。

Compose最大的优势是“把配置写成代码”。端口、环境变量、重启策略全写在一个YAML文件里，以后无论是迁移机器还是给别人复现环境，拷贝这个文件就够了。而且Compose天然支持多个容器编排，未来你想给它加个反向代理或者数据库，都不需要推翻重来。社区里现在还有不少“yolo风格”的一键部署脚本，本质也是把Compose文件打包，一条命令自动创建目录、写配置、拉镜像、启动服务，再把健康检查的状态直接打印给你。这种一把梭的玩法，部署super-productivity大概只需要两分钟，算是目前最舒服的组合。

3. 一键部署实战：从配置文件到首次打开

3.1 docker-compose配置逐行拆解

先给出一份我日常在用的docker-compose.yml，你直接复制保存成文件就行。这个配置是经过长期测试稳定的版本，不是网上随手抄来的残缺模板。

version: "3.8" services: super-productivity: image: superproductivity/super-productivity:latest container_name: super-productivity restart: unless-stopped ports: - "4040:80" environment: - PUID=1000 - PGID=1000 - TZ=Asia/Shanghai volumes: - ./sp-data:/app/data

一行行来看。image使用的是官方镜像，我没固定到具体版本号，日常家用场景用latest问题不大，后面会讲大版本升级时的注意事项。restart: unless-stopped是关键，它保证容器在系统重启或者意外退出后会自动拉起，做成服务就得有这个自愈能力。

端口映射部分，4040:80表示把容器内部的80端口暴露到宿主机的4040端口。这样你访问http://服务器IP:4040就能打开界面。如果你打算长期使用，建议不要用默认的80端口，因为80端口很可能被其他服务占用，改为一个高位端口更稳妥。TZ=Asia/Shanghai用来指定容器的时区，避免日志时间跟本地时间对不上。

最后那个volumes挂载，我顺手把./sp-data目录映射到了容器内的/app/data。因为super-productivity的数据主要存在浏览器端，这个卷更多是给未来配置文件和可能的日志输出留的空间。不过养成挂载的习惯没坏处，以后就算官方加入了服务端存储功能，你也不用重新配置。

3.2 拉取镜像、启动服务与数据初始化

配置写好之后，整个部署过程其实只剩三步，而且每一步都有明确的反馈。假设你已经建好了项目目录，把上面的内容保存为docker-compose.yml，然后在这个目录里执行：

docker compose up -d

第一次执行会先拉取镜像，这一步取决于你的网络环境。镜像文件大约一两百MB，耐心等它拉完。拉取完成后，容器会自动创建并启动。你可以用docker compose ps查看状态，看到Up（healthy）或者至少Up就说明服务起来了。如果状态是Restarting，多半是配置文件有语法错误或者端口冲突，往下翻到常见问题部分。

容器起来之后，打开浏览器访问http://localhost:4040。super-productivity的Web版没有复杂的安装向导，不会让你填数据库连接串，也不会让你设置管理员账号。页面加载完成后，你会直接进入应用主界面。首次打开会有个引导弹窗，问你要不要创建示例项目，我建议你先跳过，直接手动建项目，这样更符合自己的使用习惯。

如果你不想用Compose，就用官方一行命令的方式：

curl -sSL https://raw.githubusercontent.com/johannesjo/super-productivity/develop/bin/install.sh | bash -s -- -p 4040

这条命令会拉取官方install.sh脚本，自动完成镜像拉取和容器启动，访问端口还是4040。适合只想临时体验一下的朋友。

3.3 首次打开后的基础设置

服务跑通以后，别急着往里面堆任务，你先做几件小事，能让后面的使用体验顺畅很多。第一件是设置界面里的“语言与外观”，把界面语言切成中文，顺便按自己的喜欢调整主题色。第二件是配置日期格式和一周起始日，国内习惯周一作为一周开始，默认设置可能是周日，不调整的话日历视图怎么看怎么别扭。

第三件是我特别想强调的——立即导出一次备份。在设置里找到“备份”或“导出数据”的入口，把当前（虽然是空的）数据导出一份JSON存到本地。等到你用了两周积累了任务之后，你会庆幸一开始就建立了备份习惯。最后再全局看一眼键盘快捷键列表，这个应用快捷键设计得很顺手，比如N快速新建任务、Ctrl+Enter完成任务，记住几个高频的就够用了。

4. 从到手到精通：核心功能的组合玩法

4.1 项目与任务：把零散待办变成可执行计划

super-productivity里最重要的概念之一就是“项目”（Project）。你可以把它理解成一个个独立的任务分区，不同领域的待办互不干扰。我目前的划分是“工作项目”“个人学习”“生活杂事”三个项目，每个项目下再挂各自的任务。这样做的底气是：当我想进入工作状态时，只打开“工作项目”看板，其他琐事全部隐形。

任务本身的功能也很扎实。每个任务可以设置预计耗时，单位是分钟。比如“写周报”我标30分钟，“整理报销单”标15分钟。设置预计耗时的意义不是为了给自己制造压力，而是配合番茄钟和统计功能，让你逐渐建立起“估算能力”。很多人的时间管理一塌糊涂，根本原因是根本不知道一件事实际要花多久。用这个应用记录几周之后，你再估时间就会准很多。

任务还支持子任务、标签和优先级。我的建议是别过度设计。标签最多用三四个，比如“紧急”“耗脑”“琐碎”，优先级也只用高、中、低三档。时间管理工具的宿敌是维护成本，如果整理任务的成本超过了完成任务本身，工具就会被弃用。

4.2 番茄钟、日历与时间统计：如何形成反馈循环

真正让super-productivity从“待办清单”进化成“时间管理大师助手”的，是番茄钟、日历和统计三个模块的联动。我自己有个固定的启动流程：早上到工位，打开“今日”列表，挑出今天要做的三件关键任务，在每个任务上启动番茄钟。

启动方式很简单，任务详情旁边就有计时按钮，点一下就开始25分钟倒计时。期间如果有打断，可以暂停或者放弃这一轮。番茄钟跑完后，应用会记录这一段专注时间，并且自动累加到该任务的实际耗时上。比如我预计“写周报”要30分钟，结果实际上用了两个番茄钟加一次暂停，统计就显示实际耗时55分钟。这个偏差数据积累起来，就是你做计划时最宝贵的参考。

日历视图适合前一天晚上做“时间封箱”，也就是把第二天的时间块提前占好。上午九点到十点做深度工作，下午两点到三点处理沟通类杂事。把任务拖进日历的时间块里，第二天按照计划执行就行。到了周末，打开统计报表，看四个指标：完成任务数、专注总时长、各项目时间分布、预计VS实际耗时偏差。对着这组数据简单复盘十分钟，下周计划的合理性会持续提升。

4.3 外部集成与快捷键：进阶用户必看的效率配方

如果你是团队协作场景，外部集成就是super-productivity的另一大亮点。设置里可以连接Jira、GitHub、GitLab等平台的账户，把issue和PR自动拉取成任务。这样你个人时间管理和团队工作流就有一份统一视图了。我见过不少开发者的用法是：GitHub上被分配了issue，直接在super-productivity里启动番茄钟去处理，完成后再update回原平台，全程不用切应用。

本地使用时，键盘快捷键是提升操作速度的核心。我把最常用的一批贴出来，你照着练几次就能形成肌肉记忆：

• N：快速新建任务
• Ctrl + Enter：完成任务
• S：启动/暂停番茄钟
• 1/2/3：切换今天、明天、以后三个智能列表
• P：快速在项目之间跳转

刚开始记不住没关系，用一天就熟悉了。等你习惯了快捷键，再用鼠标一个个点按钮，会明显感觉慢半拍。

5. 常见问题与避坑实录

5.1 部署启动阶段的几个典型问题

部署过程中我踩过一些坑，也帮朋友排查过不少，典型的无非这几类。

第一是端口被占用。docker compose up -d之后，容器显示启动失败，用docker compose logs看日志，通常会明确提示端口已被其他进程占用。解决办法很简单，把compose里的4040:80改成4041:80或者任意空闲端口，重新docker compose up -d即可。

第二是白屏或一直转圈。super-productivity的Web版对浏览器版本有一定要求，太老的浏览器可能跑不起来。遇到白屏，先强制刷新（Ctrl+Shift+R），再看浏览器控制台有没有报错。如果控制台出现IndexedDB相关的报错，说明之前的本地数据可能损坏了，这时需要进入浏览器开发者工具的“Application”面板，找到IndexedDB下面的super-productivity库，手动删除数据库再刷新，应用会以全新状态启动。

第三是容器经常自动重启。多半是镜像拉取不完整或者磁盘空间不足。用df -h看下磁盘剩余，如果满了，docker system prune清理一下悬空镜像和缓存，再重新启动容器。

5.2 数据安全：备份、恢复与迁移

前面说过，super-productivity的数据默认存在浏览器本地。好处是速度快、隐私好，但对应的风险是：你换了台电脑或者清理浏览器缓存，数据就“消失”了。所以备份是日常使用中最不能偷懒的环节。官方的设置页面里有“导出备份”功能，一键生成一个JSON文件。我给自己定的规矩是每周五下班前导出一份，文件名带上日期，存到网盘里。

恢复操作同样简单。在新环境打开应用后，进入设置，选择“导入备份”，上传之前导出的JSON文件即可。整个任务体系、项目分区、番茄钟统计数据都会原样还原。如果你想把数据从A电脑迁到B电脑，用这个导出导入流程就够了。

如果你懂一点浏览器开发，还有一个更彻底的备份方式：打开开发者工具，切到Application面板，找到IndexedDB，右键导出super-productivity这个数据库。这个备份比JSON更底层，连浏览器端没暴露的本地设置都能带上。但平时没必要这么做，JSON导出已经完全够用。

5.3 长期稳定运行的建议

服务稳定跑了半年多之后，我总结出几条长期运行的经验，对任何自部署应用都适用。第一条，固定版本跑生产。官方镜像的latest标签会跟随上游持续更新，大版本升级有时会调整数据结构，可能导致旧数据在新版本里显示异常。如果你很在意数据完整性，建议把compose里的镜像版本固定到当前稳定版本号，例如superproductivity/super-productivity:v9.1.0，经过自己确认没问题再手动升。

第二条，给容器的日志设个上限。Docker默认会无限收集容器日志，时间长了可能撑爆磁盘。在compose里加一段logging配置，把单个日志文件大小限制在10MB，保留三个文件就够：

logging: driver: json-file options: max-size: "10m" max-file: "3"

第三条，配合系统级监控。因为我把它固定部署在那台老NUC上，顺手在主机上开了一个看资源占用的定时脚本，每天早晨发一封邮件报告磁盘和内存状态。很多时候容器挂了不是应用本身的问题，而是整个宿主机的磁盘满了或者温度过高导致系统崩溃。把这个底兜住，super-productivity才能真的做到“长期在线”。

最后再送上一个我的个人习惯：每天下班前花30秒，把今天没做完的任务重新设置“预计时间”，再移到明天。这个动作让明天的待办列表永远是可执行且新鲜的，不会累积一堆过期的“昨日期限”。工具再强大，也顶不过每天一次小小的清理。super-productivity给了我们掌控时间的仪表盘，但握着方向盘的手，还是自己的。