最近搬家在收拾东西的时候我彻底崩溃了工具箱找不到、备用键盘不知道塞哪个纸箱、去年买的充电器拆了三次包装愣是没找到。更要命的是为了找一把卷尺我又下单买了一把新的——然后收拾完又翻出来三把。痛定思痛我决定给自己上个资产跟踪器把家里两百多件杂物全部登记在案出门在外也能随时查某样东西放在哪个柜子。研究了一圈最后选了开源项目 DumbAssets用 Docker Compose 在本地的旧电脑上部署起来再做了一层外网访问彻底把这套系统变成随身可查的物品百科。这篇文章就把我完整的本地部署过程、外网访问的三种可行方案、以及跑通之后才踩到的那些坑原原本本写出来。适合家里东西多到记不住位置的人、工作室或小团队想管固定资产的朋友以及一切倾向于自托管、不想把家庭物品清单上传到云端服务的折腾党。内容不吹不黑都是实际操作过的经验和命令。1. 资产跟着用不走丢DumbAssets 到底能干什么DumbAssets 是一套开源的、自托管的资产跟踪 Web 应用。从名字就能看出来它的定位很朴实不搞花哨的企业级功能就是帮你记录什么东西、放在哪。1.1 先看它能提供的核心功能我选它之前列了一组必需需求DumbAssets 基本都对上了资产位置管理支持建立多级位置比如家 → 主卧 → 衣柜 → 顶层搁板每件物品都挂在一个具体位置上二维码标签系统可以给每件资产生成专属二维码打印出来后贴在收纳箱或设备本体上扫码就能看到完整信息搜索与筛选支持按名称、类别、位置筛选东西多到几百件时这个功能就是救命稻草借用归还记录能记录物品借给谁、什么时候借的、什么时候还回来。我借工具给邻居再也不用来回问那锤子还在你那吗附件支持可以把购买凭证、保修卡照片、说明书 PDF 挂到对应资产上多用户给家人开账号大家扫码都能查不需要抢同一台电脑整个界面是 Web 的手机浏览器直接打开就能用。这点很关键因为我扫码主要靠手机摄像头不需要装任何 App。1.2 和同类工具横向对比我在选择时还对比过纯 Excel 表格、Notion 模板、HomeBox 这类同类开源工具。各有各的道理但我最后选 DumbAssets理由其实很朴素Excel 和 Notion 本质是记录工具没有扫码、没有位置树、没有借还流程。东西少还行东西一多录入和查找全靠搜索表格体感很差。HomeBox 确实功能更丰富自带购买价格、保修期提醒、甚至能对接条形码扫描。但对一个只想快速把家里杂物管起来的人来说它有点重。配置项目要填不少字段录入效率反而不高。DumbAssets 的优点是录入最快、查询最直接。它默认的字段精简打开一个新增资产表单填品名、选位置、扫码保存全程不到十秒。这决定了你愿不愿意坚持用下去——一个资产管理系统如果录一条都要磨蹭两分钟我敢打赌一周后你就不想碰它了。2. 部署前想清楚的几件事环境准备与方案选型很多人一看到部署两个字就头大觉得要装一堆依赖、配一堆环境。其实用 Docker Compose 之后整个流程被简化成写一个配置文件 → 拉镜像 → 启动三步。但为了让后面不出幺蛾子部署前有四个问题得先想明白。2.1 服务器选型不一定非买云主机DumbAssets 本身不重对硬件要求很低。我用的是一台退役的旧笔记本电脑刷了 Debian内存 4G硬盘是老旧的机械盘。平时跑着这套系统加一个下载服务负载完全没压力。你可以依据自己的实际情况选择宿主机闲置电脑 / 迷你主机适合放家里电费可控性能无压力NAS群晖/威联通/开源 NAS 系统多数 NAS 支持 Docker直接把 Compose 工程放到 NAS 上就行云主机如果你本来就有台常年打开的云主机也可以部署在上面外网访问天然解决操作系统我建议用 Debian 或 Ubuntu 这类主流 Linux 发行版。Windows 机器也能跑 Docker Desktop但内存占用更高而且文件路径、权限问题会多一些个人不推荐作为长期运行方案。内存 1G 以上、硬盘留 10G 左右就够跑了。DumbAssets 的元数据很小大头一般花在物品照片和附件上。2.2 为什么我用了 Docker Compose 而不是直接装DumbAssets 本身依赖 Web 服务环境 数据库。如果直接在宿主机上装意味着你要自己管理运行时环境、依赖版本和进程生命周期哪天想迁移换机器光搬家就得折腾半晚上。Docker Compose 的价值在于它把整套东西文件化了应用容器、数据库容器、数据卷、端口映射全写在一个docker-compose.yml里。换机器时把这个配置文件一拷执行docker compose up -d服务就原样起来了。更现实的好处是容器崩溃了能自动重启日志在统一位置查看数据卷也能单独备份。这些能力对一个小型自托管服务来说省心程度是质的提升。2.3 数据库和数据卷规划DumbAssets 可以配合 PostgreSQL 使用也有默认使用轻量级数据库的版本。我采用的是应用容器 PostgreSQL 数据库容器的方式数据卷分别挂载两个目录一个目录挂应用数据也就是存放资产记录、位置树、系统配置的地方一个目录挂上传文件也就是物品图片、附件、打印标签时生成的二维码文件把数据库数据和上传文件分开挂载好处是一条docker compose up -d就能同时管理两边。备份的时候也可以按类型分别打包后面我在维护心得部分会专门讲。3. Docker Compose 部署 DumbAssets从目录结构到页面出现下面这部分是实际操作我从头到尾走一遍命令。我的宿主机 IP 是192.168.1.100做演示的部署端口用8080你可以按自己的环境替换。3.1 准备目录结构和配置文件先建好工程目录避免文件散落mkdir -p ~/dumbassets/data mkdir -p ~/dumbassets/media cd ~/dumbassets vim docker-compose.ymldocker-compose.yml的核心内容如下。镜像名我写成dumbassets-server和postgres实际部署时请以你拉取到的具体镜像名为准不同版本的默认端口可能不同version: 3.8 services: app: image: dumbassets-server:latest container_name: dumbassets restart: unless-stopped ports: - 8080:8000 environment: - SECRET_KEY请改成一段足够随机的长字符串 - ALLOWED_HOSTS* - DATABASE_URLpostgres://dumbassets:数据库密码db:5432/dumbassets volumes: - ./data:/app/data - ./media:/app/media depends_on: db: condition: service_healthy db: image: postgres:16-alpine container_name: dumbassets-db restart: unless-stopped environment: - POSTGRES_DBdumbassets - POSTGRES_USERdumbassets - POSTGRES_PASSWORD数据库密码 volumes: - ./db_data:/var/lib/postgresql/data healthcheck: test: [CMD-SHELL, pg_isready -U dumbassets -d dumbassets] interval: 10s timeout: 5s retries: 5这里有几个关键点列出我的考量ports里的8080:8000表示宿主机 8080 端口映射到容器内 8000 端口。你自己访问时用http://192.168.1.100:8080而不是 8000SECRET_KEY不要随便填changeme。这个密钥用于会话加密和签名一旦被外部拿到可推断安全就形同虚设。可以用openssl rand -base64 48生成一段ALLOWED_HOSTS*先用通配符方便跑通但如果你对外网暴露了这个服务后面做安全加固时务必要改掉我会在第四章细说healthcheck是为了让应用容器在数据库真正就绪后才启动避免出现连接数据库失败的经典报错如果你的 DumbAssets 版本自带 SQLite 或者其他内置数据库就不用写db这个服务直接把数据卷挂给应用容器即可。写好后启动docker compose pull docker compose up -d docker compose logs -f --tail100看到日志里出现类似 listening on 8000 之类的输出就说明服务已经起来了。3.2 初始化账号与登录打开浏览器访问http://192.168.1.100:8080第一次进入会看到初始化页面通常需要设置管理员账号和密码。这里的建议是不要用太短的口令至少 12 位以上混合大小写和数字管理邮箱不一定要真实邮箱本地部署没有邮件验证环节除非你自己配了邮件服务记好密码和数据库信息建议放进密码管理器之后就能看到资产列表页、位置管理页和二维码标签页。到这里本地部署就算完成了。3.3 部署过程常见问题第一次部署不是人人都顺利我把踩到过的几个问题按排查顺序写出来端口被占用。如果执行docker compose up -d时报端口冲突说明宿主机 8080 被其他程序占了。可以用sudo lsof -i :8080查看占用进程或者直接把 compose 里的8080改成18080。我建议改成高位端口至少能挡掉一些无差别扫描。容器反复重启。90% 的原因是数据库没就绪。检查方式很简单docker compose logs app如果看到 connection refused 相关日志说明 app 比 db 启动早。我已经在 compose 里加了condition: service_healthy正常不会再犯但如果你的 Compose 文件是从旧版本改来的务必确认这行存在。权限导致数据目录写不进去。宿主机上./data和./media如果属于 root容器内用户可能没权限。简单粗暴的解决办法sudo chown -R 1000:1000 ~/dumbassets/data ~/dumbassets/media1000 是多数容器内默认非 root 用户的 UID。如果你不确定可以先不执行 chown看容器日志报什么错误再对症处理。4. 外网访问的三条可行路径从端口映射到隧道本地部署完成只是第一步对我来说真正刚需是外网访问。理由很简单比如我在公司的仓库里突然想知道那套备用螺丝刀放在家里的哪个抽屉以前只能打电话让家人翻箱倒柜现在直接打开手机访问资产系统的页面十秒钟就查到了。外网访问的方案不止一种我不打算只给一条路而是把三种主流做法都写清楚你自己按条件选。4.1 方案一路由器端口映射 DDNS最朴素也最依赖公网 IP这个方案的前提是你家宽带确实分配到了公网 IP不管 IPv4 还是 IPv6。判断方法很简单登录路由器管理页面看 WAN 口 IP 跟访问IP查询网站看到的是不是一致。一致说明就是公网 IP。操作步骤在路由器管理后台找到端口映射虚拟服务器或端口转发配置页把公网的某个端口比如 18080映射到内网宿主机 IP 的 8080 端口如果路由器自带 DDNS 功能绑定一个域名比如yourname.ddns.net解决公网 IP 变动问题在外网访问http://yourname.ddns.net:18080这个方案最大的优点是没有额外的服务器成本数据转发路径最短速度最快。缺点也明显一是公网 IP 能不能拿到取决于运营商有时候同一家运营商的不同地区规则都不一样二是直接把内网服务怼到公网上安全风险最高。我自己做这个方案时加了一层额外防护路由器防火墙里只放行来源国/来源 IP 段但这个配置不一定所有路由器都支持。如果你只有 IPv6 公网地址路由器端口映射要对 IPv6 端口做配置而且外网访问的时候对端设备也得支持 IPv6。现在手机流量基本都支持了但一些人、一些公共 Wi-Fi 环境可能不支持这个要自己测。4.2 方案二Cloudflare Tunnel不需要公网 IP 也能安全暴露如果判断了半天发现自己根本没有公网 IP就不用折腾端口映射了。Cloudflare Tunnel 是我现在主力在用的方案。它的原理是你的服务器主动向外连到 Cloudflare 的边缘节点维持一条双向隧道Cloudflare 再把公网请求通过隧道转发到你的内网服务。也就是说内网机器不需要有公网入口也能被外网访问到。具体操作流程准备一个域名DNS 托管到 Cloudflare在服务器上安装cloudflared官方文档有各系统的安装命令创建隧道cloudflared tunnel login cloudflared tunnel create dumbassets-tunnel配置隧道路由编辑~/.cloudflared/config.ymltunnel: dumbassets-tunnel credentials-file: /home/你的用户名/.cloudflared/dumbassets-tunnel.json ingress: - hostname: assets.yourdomain.com service: http://localhost:8080 - service: http_status:404给 DNS 添加CNAME assets.yourdomain.com → 隧道ID.cfargotunnel.com或者在 Cloudflare 面板的 Tunnel 页面自动配置启动并注册为系统服务cloudflared tunnel run dumbassets-tunnel sudo systemctl enable cloudflaredCloudflare Tunnel 相比端口映射的好处有三个不依赖公网 IP天然带 HTTPS不用自己折腾证书别人扫描你的域名只能扫到 Cloudflare 的防护节点扫不到你家里这台旧电脑。代价是访问路径变成用户 → Cloudflare → 你家服务器多了一层中转速度和稳定性取决于你所在地区到 Cloudflare 边缘节点的质量一般家用足够。如果担心访问者过多可以在 Cloudflare 面板开启 Access 身份验证给域名加一层邮箱 OTP 或 Google 登录。这样就算是暴露在公网没有你的授权也进不来。4.3 方案三frp 内网穿透灵活但要自备云主机frp 是另一个经典思路适合你已经有一台带公网 IP 的云主机的情况。它在云主机上运行frps服务端在家里旧电脑上运行frpc客户端两边建立一条加密连接再把公网端口流量转发到内网服务的端口。云主机上启动frps配置文件写bindPort 7000 auth.token 这里填一段强随机token家里机器上启动frpc配置文件写serverAddr 你的云主机公网IP serverPort 7000 auth.token 这里填一段强随机token [[proxies]] name dumbassets type tcp localIP 127.0.0.1 localPort 8080 remotePort 18080然后分别启动两个服务就可以。外网访问http://你的云主机IP:18080。frp 的优势是可控性很高端口、加密、负载均衡都能调。代价是云主机要花一点钱带宽决定访问速度而云主机的流量费用普遍不便宜。如果你手里的云主机本来就是别的服务在用的顺带跑一个 frps那这个成本约等于零。4.4 外网访问的安全加固这条必须单独说不管选哪条路只要服务暴露到公网就一定会有扫描器和嗅探流量。我实测下来的观察是一个没有任何防护的 HTTP 服务暴露在公网上不出 24 小时就有自动化程序来探测。所以以下几件事我全部做了应用侧改掉默认管理员口令ALLOWED_HOSTS不再写*改为你实际使用的域名或固定的 IP 列表入口侧端口映射方案坚持开 HTTPS别用裸的 HTTP。用 Caddy 或者 Nginx 反代加证书是最省事的做法访问侧能用 Cloudflare Access 就加一层身份验证能用防火墙 IP 白名单就限制来源 IP操作侧给cloudflared、frpc都做成系统服务日志记录保留至少一周出现异常登录日志能追溯具体到 DumbAssets 应用本身还可以给它套一层反向代理用户请求先进到 Nginx再由 Nginx 转发到localhost:8080。Nginx 层可以顺手做请求频率限制、拦截无效路径、统一输出访问日志。相信我这套组合拳打下来攻击流量基本都会被挡在外面。5. 把资产数据真正用起来从录入到扫码归位部署和外网访问搞定后真正的重头戏才刚开始怎么让家里人愿意用、坚持用、用得顺手。我做这套系统的核心思路是把录入成本和查询成本都压到最低。5.1 设计位置体系先框架后细节不要一上来就录具体物品而是先把位置树搭好。我给自家建的结构类似这样家玄关书房书桌左抽屉书桌右抽屉客厅电视柜 → 下层收纳盒储物间货架A → 第2层货架B → 第1层位置命名建议具体到哪个柜子哪一层而不是笼统的客厅。位置层级越细后面找东西越快但也要考虑实际维护成本太碎了反而不方便一次归位。收纳盒这种层级我觉得刚刚好。5.2 录入技巧尽量把信息一次填全我录入时遵循两个原则品名写常见的搜索词比如博世电钻 GBH 2-26而不是单纯写电钻。搜索时你大概率会记得品牌或型号片段能拍照就拍照。物品照片比文字描述直观得多找闲置手机或卡片相机拍一张冲印盒的正面照比写十行备注都有用录入完成后建议立刻打印二维码标签。DumbAssets 生成的二维码通常是一个对应资产详情页的链接打印成标签后贴在收纳箱侧面。由于二维码里通常存的是完整 URL局域网内扫码没问题但如果你要在外网访问二维码的 URL 最好指向你在外网用的域名。这点要特别注意我帮朋友弄时两次都踩在这个上面打印出来的二维码只能在局域网用外网扫就提示域名不对。5.3 借还流程要简单到不增加任何负担我给家人设置的使用规则是借出打开系统找到对应资产点借出填借给谁归还扫二维码或搜索资产点归还不要给这个流程增加任何必须写备注必须拍照之类的强制项。一旦操作变得繁琐家人很快就会放弃使用。等大家用顺了再慢慢调成可选的备注项系统价值才会随着时间积累出来。5.4 定期盘点看着不起眼但很管用光有记录不盘点数据会逐渐失真。我的做法是每隔一个季度把所有位置的清单导出来走到柜子前对照一遍把已经搬走却还没更新位置的物品挪到正确位置顺便断舍离一批用不上的东西。盘点最大的收益其实是发现你已经不记得但确实存在的东西。第一次盘点时我给这个季度省下的麻烦下了个定义没再买过重复的网线、螺丝刀和分线器。6. 跑了几个月之后的维护心得与后续扩展最后这部分是我真正长期稳定运行后才总结出来的维护经验写在这里避免大家再走弯路。6.1 备份要分成两部分处理DumbAssets 的数据分成数据库里的结构化数据和上传的图片/附件文件。我最开始只备份了数据目录结果一次系统异常后资产记录全在但所有物品照片全部丢失原因是忽略了媒体文件的挂载目录。现在我的备份策略是docker compose exec -T db pg_dump -U dumbassets dumbassets $(date %Y%m%d)_db.sql tar czf $(date %Y%m%d)_media.tar.gz ~/dumbassets/media数据库导出用pg_dump文件附件直接用 tar 打包。两个备份文件放到不同目录至少保留最近 30 天的副本。如果你部署用的是 SQLite 版本备份逻辑更简单直接拷对应的.db文件就行但也要注意保持一致性最好先停应用再拷。6.2 镜像升级不要拍脑袋DumbAssets 这种项目迭代不算慢新版本偶尔会修 bug、加功能。但我升级过一次后就不太敢轻易动了直接把镜像 tag 从某个旧版本拉成latest结果数据库迁移脚本把字段结构改了旧数据差点回滚不出来。现在我的原则是升级前先备份全部数据升级时先拉新镜像按新版启动容器观察页面和接口是否正常确认没有问题后至少再保留旧版镜像的 tag 一周出问题可以马上docker compose down 切回旧 tag up。6.3 和 Home Assistant 联动的后续思路资产管理系统不是终点它和智能家居系统放在一起才更有想象力。我现在把 DumbAssets 的数据通过定时轮询接口拉取到本地的 Home Assistant 里家庭仪表盘上能直接看到哪件物品最近被移动过哪些位置长期没变化。比如储物间货架 B 第 1 层的所有物品三个月都没动过说明它们大概率可以清理或者物品已经不在家这个信息对定期断舍离非常有参考价值。这一步是探索性的目前我还没有做自动化决策只是把数据打通作为提醒。但对一个自托管项目来说能用开放接口把数据重新用起来这件事本身就很有乐趣。最后说点实际的如果你家东西不算太多也许一个贴好标签的抽屉就够了不一定需要专门部署一套系统。但像我这样把所有东西都登记在册并且能在外网随时查的人最直观的体验是买东西之前先查有没有、找东西之前先查在哪、借东西给别人之前查谁借了。这套系统改变的不是整理能力而是重新拥有对物品位置信息的掌控力。折腾它花掉周末的一个下午但往后每次找东西的时候我都在暗自感谢那个下午。