企业官网建设流程全解析

从零部署Wallos：打造专属预算管理平台

1. 项目概述：Wallos到底在解决什么问题

1.1 个人财务管理的三个真实痛点

先聊一个很现实的问题：你的钱到底花在哪了？我把近两年的流水拉出来看，最大开销不是房租不是吃饭，而是一堆“看起来很小”的订阅服务——视频会员、音乐、云盘、域名、VPS、AI工具API，加起来一个月居然有三百多块，一年就是四千多。这种钱最大的特点就是“每笔不多，累积惊人”，而且容易被忽略。等到扣费短信弹出来才意识到，有些服务已经续费好几个月，自己却压根没用过几次。

第二个痛点是跨平台记账的繁琐。市面上主流记账App我基本都试过，要么数据存在别人服务器上，隐私没有保障，要么功能太重，每次记账要选分类、选账户、填备注，三个月下来就坚持不住。还有一个很实际的问题：很多记账工具不支持多币种，或者只有付费版才开放统计功能。我人在国内，偶尔有海外收入，币种一混，账单立刻变成一团浆糊。

第三个痛点是“预算控制”停留在嘴上。你告诉自己“这个月少花点”，但缺少一个工具告诉你：我到底超了没有、还差多少到预算线、哪些类别已经接近上限。等你自己反应过来，钱已经花完了。

这三个痛点叠加在一起，我一直在找一套能长期用下去的解决方案，最后锁定了Wallos。

1.2 Wallos的核心功能拆解

Wallos是一个自托管的开源财务管理工具，技术上基于PHP和MySQL/MariaDB，功能设计上紧紧围绕“订阅管理”和“预算控制”两个核心。

它的仪表盘能直接看到当月支出总额、可用预算、活跃订阅数量，以及最近七天的消费趋势曲线。订阅管理支持按周、月、季度、年等不同计费周期记录，自动算出下次扣费日期，还能给即将到来的账单设置提醒。“预算”模块可以按类别设置月度限额，比如餐饮、交通、娱乐各设一个数，每笔支出记账后自动扣减对应类别额度，用图形标出剩余预算。它还内置了支出和收入流水、分类管理、多账户（比如现金、信用卡、储蓄卡）、多币种汇率换算，以及数据导出。最让我在意的一点是，所有数据都存在你自己的数据库里，跟云端服务彻底脱钩。

1.3 什么人适合用Wallos

对号入座的话，适合用Wallos的人大概有三类：一是有大量订阅服务、需要做“订阅健康检查”的人；二是想建立月度预算习惯、希望每笔开销都有地方记录的普通人；三是已经跑着其他自托管服务（比如家里有NAS、VPS上挂着其他容器），纯粹想把数据控制权握在自己手里的玩家。前两类人是主力用户，第三类人则是“顺手就会去部署”的天然受众。

我自己属于第一类和第三类的混合体：订阅多、又不想用别人的云服务。如果你跟我情况类似，这篇文章应该能帮你少走不少弯路。

2. 部署方案选型：为什么必须用Docker

2.1 传统安装与容器化部署的横向对比

Wallos的官方文档提供了多种安装方式，但部署路径大致分两类：传统LAMP/LEMP环境安装和Docker容器化部署。

传统方式要在服务器上装好Nginx或Apache、PHP 8.1以上版本、Composer、MariaDB，然后手动clone源码、安装依赖、配置虚拟主机、设置数据库连接。这套流程对于只部署过一两个服务的人来说并不轻松，而且最容易出问题的是PHP扩展版本对不上、权限没给够、伪静态规则写错这种让人崩溃的细节。一旦后续要升级版本，还得重新走一遍环境检查和源码更新的流程，操作成本不小。

Docker Compose方式则是把Web服务、PHP运行环境、数据库全部封装进容器，宿主机器上只要有一个Docker环境即可。升级版本只需改一下镜像tag后重新拉取，数据用volume挂载在宿主机上，备份和迁移都非常方便。这跟很多人在本机部署大模型、安装其他自托管应用时的方式一致——容器化已经成为部署类工具的主流姿势。

我自己在部署Wallos前已经在同一台VPS上跑了好几个容器，包括持续集成用的Jenkins、监控用的Prometheus，以及一些日常工具，对这些服务的管理维护已经习惯用Docker Compose统一编排。所以毫不犹豫选了容器化方案，不折腾系统环境，也是后续能长期稳定运行的前提。

2.2 运行环境要求与最简配置参考

Wallos本身是轻量应用，资源占用并不高。官方推荐的最低配置比较保守，但实际跑下来，我用过的配置如下：

如果你手头只有一个跑着其他服务的服务器，完全不冲突。我部署Wallos的这台VPS同时跑着Nginx反代、监控采集器和几个定时任务，Wallos的两个容器加进来后，内存占用一共多出大约350MB左右，CPU占用平时几乎为零。也就是说，这台机器从1GB内存升级到2GB后，部署Wallos是绰绰有余的。

2.3 部署位置：VPS、NAS还是本地小主机

部署位置的选择会影响后续使用体验。我见过三种方案，各有侧重点：

第一种是部署在国外VPS上。优点是有固定公网IP，访问不受家里网络环境影响，后续还可以配上域名和HTTPS证书，出门在外随时打开看账单。缺点是需要额外支付服务器费用，且网络链路质量取决于服务商。

第二种是部署在家里的NAS上。很多人的群晖或威联通本来就在跑Docker，与Wallos的契合度很高。数据完全存在于本地，隐私性最强，访问速度也有保证。但外网访问要处理内网穿透或IPv6，对没有公网IP的用户稍麻烦。

第三种是本地小主机。比如用树莓派或淘汰下来的旧笔记本，长期开机专跑家庭服务。适合对隐私有极致要求的人，但断电、网络稳定性都是需要考虑的因素。

我自己的选择是VPS方案，因为这台机器本身就是自己的资产，而且后续可能还要在上面部署更多服务，Wallos只是其中一个容器。如果你家里已经有NAS且在运行Docker，直接部署在NAS上更合理。这个选择没有绝对对错，关键是明确自己的访问需求和数据保管偏好。

3. 从零开始：完整部署流程与Compose配置

3.1 准备好你的docker-compose.yml

我采用的是Docker Compose方式，这也是官方推荐的主流做法。先在服务器上建好项目目录：

mkdir -p /opt/wallos cd /opt/wallos touch docker-compose.yml

然后编辑docker-compose.yml。下面这份配置是我自用的版本，经过多轮调整后已经稳定运行了两三个月：

version: '3' services: wallos: image: bellamy/wallos:latest container_name: wallos restart: unless-stopped ports: - "8282:80" volumes: - ./wallos-data:/var/www/html depends_on: - wallos-db environment: TZ: Asia/Shanghai wallos-db: image: mariadb:10.11 container_name: wallos-db restart: unless-stopped environment: MYSQL_ROOT_PASSWORD: change_this_root_password MYSQL_DATABASE: wallos MYSQL_USER: wallos MYSQL_PASSWORD: change_this_db_password volumes: - ./wallos-db-data:/var/lib/mysql

这里有几个关键点值得多说几句。

镜像选择：镜像名以官方仓库当前信息为准，不同时期可能有变化。bellamy/wallos:latest是我部署时常用的一个构建镜像，也有用户使用ghcr.io上的官方镜像。如果你拉取的是其他版本，注意确认和数据库的兼容性，尤其是PHP版本和宿主的架构（x86_64还是arm64）。同一时间只保留一份镜像，别让old和new两个tag并存，否则容易搞不清自己跑的到底是哪个版本。

端口映射：宿主机的8282端口映射到容器内的80端口。之所以不用80，是因为我这台VPS上已经由Nginx占用了80/443，8282这个高位端口交给Wallos，后续想加域名反代也方便。如果你不打算加反代，直接映射成80:80也是可以的，但要确保宿主端口没有被占用。

数据卷挂载：把宿主机上的./wallos-data映射到容器内的/var/www/html，这个是Wallos代码和数据所在目录。数据库单独挂载./wallos-db-data到MariaDB的数据目录，这样数据库文件也能独立保存。两个目录分开挂载的好处是，将来重装Web容器时数据库还在，反过来如果只想保留程序文件、数据库重来，也只需要删掉db目录即可。

数据库密码：MYSQL_ROOT_PASSWORD和MYSQL_PASSWORD务必替换成自己的强密码。很多人第一次部署图省事用默认密码，结果安全隐患非常大，后面改起来又要重建容器，非常麻烦。

3.2 启动容器与验证服务

配置写好后，启动命令非常简单：

docker compose up -d

第一次执行时，会从远端仓库拉取Wallos和MariaDB的镜像。如果服务器网络稳定，几分钟就能完成。拉取镜像时我遇到过两次问题：一次是网络超时，一次是镜像体积较大导致下载中断。解决办法是换一个网络时段再试，或者配置好镜像加速源，多试几次基本都能成功。

启动完成后，先用docker compose ps查看容器运行状态：

CONTAINER ID IMAGE STATUS PORTS f3c8a2b9e1e2 bellamy/wallos:latest Up About a minute 0.0.0.0:8282->80/tcp 5b7e2d1a6c47 mariadb:10.11 Up About a minute 3306/tcp

两个容器都是Up状态就说明基础服务没问题。此时在浏览器里访问:8282（比如http://你的服务器IP:8282），能看到Wallos的初始化页面。第一次打开时页面会自动进入安装向导，要求你填写数据库连接信息。这里的关键是：数据库容器名是wallos-db，由于两个容器在同一个Docker网络中，数据库地址不要填localhost或127.0.0.1，而是要填服务名wallos-db。端口填3306，数据库名、用户名、密码填docker-compose里对应的三个环境变量值。

这一步如果填错，页面上会直接提示数据库连接失败。我当时就犯过这个错——把数据库地址填成了服务器公网IP，结果一直连不上，后来改成容器服务名才顺利通过。第一次接触容器互联的新手特别容易踩这个坑。

3.3 首次登录与基础配置

安装向导完成后，用默认管理员账号登录后台（具体默认账号建议看官方文档，因为不同版本可能不同）。登录后第一件事不是急着录账单，而是先把“设置”里的基础参数配好。

语言选择界面直接切换到简体中文。然后设置默认货币。Wallos内置了多币种支持，你可以选出常用币种作为默认货币。如果你有外币账户，还可以在“货币”设置里维护汇率，Wallos会自动按汇率换算成你设定的基准货币来统计总支出。这个功能对经常有跨境消费的人非常友好，也是我放弃其他记账App而选择Wallos的重要原因之一。

接着设置时区。前面docker-compose里已经通过TZ环境变量指定了Asia/Shanghai，但网页端设置里可能还有自己的时区选项，两个地方都要确认一致，否则日期统计会错位。最后是通知设置，如果你希望账单到期前收到提醒，可以在此配置邮件通知服务器。我的经验是先用自己域名邮箱的SMTP服务测试，填好发送方、授权码、接收方邮箱后，保存并测试发一封，确认能收到再启用订阅提醒功能。

4. 日常使用与数据维护：让Wallos真正可持续运行

4.1 订阅管理：记清楚每一笔续费

Wallos最核心的使用场景就是订阅管理。在“订阅”页面里，每次新增订阅要记录这几个字段：订阅名称、费用金额、计费周期（周/月/季/年）、首次扣费日期，以及所属分类。我建议给每个订阅补上备注，比如“年费套餐，含两个子账户”，方便日后回忆。分类我会单独维护一套自己的体系，比如“视频/音乐/云服务/域名/软件工具/AI服务”，每个订阅归属一个分类，统计时一目了然。

这里有一个值得养成的习惯：到期日尽量设为实际扣款日，而不是开通日。例如某会员是每月15号扣费，你10号开通的，那“首期扣费日”就填15号，这样Wallos推算下次扣费日更准确。订阅到期前，Wallos会在仪表盘上高亮提醒，配合邮件通知，基本上不会存在“某会员默默扣了大半年”的情况了。

预算设置方面，我按分类设了月度上限。比如“娱乐”类别每月300元，“云服务”每月200元。每录入一笔支出，该分类的剩余预算会自动减少。这比月底看总账单再反思要有效得多——消费趋势是持续可见的，不用等到月底才醒悟。

4.2 数据备份与恢复实操

自托管服务最大的隐忧就是不可恢复，所以备份必须做在前面。Wallos的数据主要包括两部分：程序目录里的配置和数据库。程序目录通过volume挂载在./wallos-data，数据库通过另一个volume挂载在./wallos-db-data。一种比较省事的备份方式是直接用mysqldump导出数据库，再加tar打包整个数据目录。

我写了一个简单的备份脚本，每天凌晨通过cron执行：

#!/bin/bash BACKUP_DIR=/opt/wallos/backups DATE=$(date +%Y%m%d) mkdir -p $BACKUP_DIR docker exec wallos-db sh -c 'exec mariadb-dump -u root -p"$MYSQL_ROOT_PASSWORD" --all-databases' > $BACKUP_DIR/wallos-db-$DATE.sql tar -czf $BACKUP_DIR/wallos-data-$DATE.tar.gz -C /opt/wallos wallos-data find $BACKUP_DIR -type f -mtime +30 -delete

脚本里find的作用是自动清理30天前的备份文件，防止磁盘被撑爆。恢复时，先把容器停掉，解压数据目录，再把SQL文件导入数据库，重新启动容器即可。整个过程我只完整恢复测试过一次，但就是这次测试，让我发现了一个官网文档没写清楚的坑：数据库容器的用户名和密码如果直接在compose里改了，恢复时导出的SQL会包含这些新凭据，恢复到新环境时容易因为mysql库中的user表不一致而连不上。稳妥做法是恢复前创建好同名数据库和用户，再导入业务库数据，而不去碰mysql库里的系统表。

4.3 多账户与多币种的使用细节

我平时会用现金、信用卡、储蓄卡三个账户，每笔支出记录时选择来源账户。这个习惯的好处是月底能看出信用卡花销是否超标，也能对照银行账单做核对。Wallos在“账户”里维护这些账户，并支持账户余额初始值。每次录入支出后，对应账户的余额会自动扣减，相当于轻量版的记账本。

如果你是跨境消费比较多的人，多币种值得多花十分钟去配置。Wallos的宽松做法是允许每个账户设置独立币种，比如一张美元信用卡，币种设为USD。记账时如果选了美元账户，Wallos会按照全局汇率表自动换算成基准货币（比如人民币）来汇总统计。刚开始用的时候，我发现每月的总支出和真实账单总有几十块的误差，排查后才发现是汇率设置落后了。后来我改成每个月1号手动更新一次汇率，误差基本控制在合理范围内。它虽然没有一些商业软件那般全自动接入实时汇率，但胜在可控。

4.4 反向代理与HTTPS访问

如果只有IP:端口方式，用一两个月就足够不耐烦了。尤其是每次打开都要输入一串数字IP和端口，手机上想看一眼账单都嫌麻烦。我后来用自己的域名给Wallos加了一个子域名，通过Nginx反代，再配上HTTPS证书。这里分享一个最简的Nginx反向代理配置片段：

server { listen 80; server_name wallos.example.com; location / { proxy_pass http://127.0.0.1:8282; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }

如果你用Caddy，那更简单，只要在Caddyfile里写一行wallos.example.com { reverse_proxy 127.0.0.1:8282 }，证书自动签发和续期，不用手动维护。HTTPS这层加上之后，Wallos的体验才真正称得上“平台级”，手机浏览器打开就是一个干净清爽的财务管理页面，数据在传输过程中也有保障。

5. 部署与使用中常见问题及排查流程

5.1 容器反复重启

这是部署初期最常遇到的问题。docker compose ps显示容器一直在Restarting，docker compose logs wallos会给出具体的错误信息。我遇到过的情况有两种：第一种是镜像本身和宿主系统架构不匹配，比如在arm64的机器上用了x86版的镜像，运行起来直接报exec format error，解决办法是换用arm64的镜像。第二种是数据目录权限不对，容器内Web进程没有写权限，此时检查并修正目录属主即可。

5.2 数据库连接失败

前面提到过，初次安装向导时数据库地址填了localhost，导致一直连不上。容器里的Web服务访问的是同网络中的数据库服务名，不是宿主机的IP。如果你的compose里数据库服务名是wallos-db，那么在安装向导里填wallos-db即可。另外，确认数据库容器健康后再执行安装向导，不要一上来就填数据，docker logs wallos-db能看到MariaDB是否完全初始化完成。

5.3 时区错乱导致统计不对

这个问题不仔细看还真容易被忽略。容器TZ环境变量设了Asia/Shanghai，但网页设置里的“日期格式/时区”如果还停在默认值，会出现某一笔支出的归属日期和实际消费日期对不上。排查时不要只看仪表盘，先到设置里核对两处时区是否一致，再回流水里看具体日期。我曾经一度以为记账逻辑出了问题，最后发现纯粹是时区没同步。

5.4 升级Wallos版本

自托管服务的好处是版本升级完全自主可控。Wallos发新版后，至少隔几天再升级，等社区反馈稳定了再动。我升级的常规步骤是：先备份数据库和程序目录，然后进入项目目录执行docker compose pull拉取新镜像，再docker compose up -d重建容器，最后查看容器日志确认无报错。升级后如果发现页面样式或功能异常，优先检查浏览器缓存，其次看数据库是否需要执行迁移脚本。切记，任何升级都比不上备份可靠，只要备份在手，升级失败也能回滚。

5.5 常见问题速查表

6. 一些个人实践后的体会

坦白讲，部署Wallos本身并不是一件多高技术门槛的事，一个熟手半小时内就能跑起来。但真正让这个平台长期发挥价值的，是持续维护数据、每周花几分钟对一次账、每月看一眼订阅到期提醒。部署完成后，我把它接进了自己的日常循环里：每月月初更新一次汇率，月底导出一份流水，看看各分类预算执行情况。这样的习惯坚持下来，“钱去哪了”这个问题终于不再是凭感觉猜了。

最后分享一个额外的小技巧：如果你和我一样在VPS上同时跑着多个服务，建议给Wallos单独创建一个Docker网络外的目录结构（比如/opt/wallos），把所有相关文件、备份、compose文件都放在同一个目录下。后续不管是迁移还是灾备恢复，只需要打包这个目录转移到另一台装好Docker的机器上，docker compose up -d一跑，整个平台就再次活过来了。这种“一个目录一个服务”的组织方式，是我在长年维护多容器服务过程中养成的习惯，对你管理其他自托管应用同样适用。