DailyTxT 2.6.4 配置参数详解

目标：系统梳理 DailyTxT 2.6.4 的全部配置面——实例级环境变量（SECRET_TOKEN、ALLOW_REGISTRATION、BASE_PATH、ALLOWED_HOSTS、INDENT、LOGOUT_AFTER_DAYS 等）的默认值、生效方式与实测行为，以及用户级设置、加密参数与数据文件格式，全部结论来自真实容器逐项验证。已在 Ubuntu 26.04.1 LTS（x86_64，Docker 29.9.2 / Compose v5.6.1，镜像 phitux/dailytxt:2.6.4）实测通过。

一、环境信息

• 操作系统：Ubuntu 26.04.1 LTS（x86_64）
• Docker：29.9.2，Compose v5.6.1
• DailyTxT：2.6.4（官方镜像 phitux/dailytxt:2.6.4，查询日期 2026-11-01）
• 主实验实例：容器 dailytxt-264-web，宿主端口 8137 → 容器 80（nginx），数据卷 ./data → /data，compose 项目 dailytxt-264-stack
• 对照实验实例：docker run 临时容器（无 env 默认配置、多 env 覆盖配置各一个，实验后即删）
• 部署过程与 compose 文件见 《DailyTxT 2.6.4 Docker Compose 部署指南》，本篇专注配置参数本身

DailyTxT v2 没有独立的配置文件：实例级行为全部由环境变量驱动（Go 后端启动时读取），用户级偏好（语言、主题、地图等）则加密存在数据目录里、通过 Web 界面或 API 修改。这是与 v1（Python/Flask）最大的配置差异之一。

二、前置条件

• 已按 B2 篇完成部署，容器处于运行状态；
• 持有任一可登录账号（本文演示用 admin / q1w2e3r4）；
• 管理面板实验需环境变量 ADMIN_PASSWORD（演示值 q1w2e3r4）；
• 能执行 docker logs / docker exec / curl。

三、参数查看与修改方式

3.1 查看生效配置：后端启动日志

Go 后端每次启动都会打印解析后的完整配置块，这是确认"环境变量到底生效没有"的最直接手段（实测回显，主容器）：

docker logs dailytxt-264-web 2>&1 | grep -A 10 "Detected the following settings"

Detected the following settings:
================
Data Path: /data
Development Mode: false
Secret Token: HaRYb2wrB0XyBtANrOkfjSaWAgQOkp5O1bweO0zu/ao=
Logout After Days: 40
Allowed Hosts: []
Indent: 4
Allow Registration: true
Base Path: /
================

⚠️ 注意：Secret Token 会明文打进日志。日志外发（采集到集中日志平台等）时务必脱敏，或接受 token 泄露即等于可伪造任意用户会话的事实。

3.2 查看运行时配置：管理面板 API

POST /api/admin/get-data（需登录态 + ADMIN_PASSWORD）返回服务端解析后的 app_settings 与磁盘占用，其中 token 做了脱敏（实测回显）：

curl -s -b cookies.txt -X POST http://127.0.0.1:8137/api/admin/get-data \
  -H 'Content-Type: application/json' -d '{"admin_password":"q1w2e3r4"}'

{"app_settings":{"data_path":"/data","development":false,"secret_token":"","logout_after_days":40,"allowed_hosts":[],"indent":4,"allow_registration":true,"base_path":"/"},"free_space":115002691584,"old_data":{"exists":false},"users":[{"id":1,"username":"admin","disk_usage":1437}]}

3.3 修改方式

改环境变量后重建容器即可（compose 场景）：

docker compose up -d    # 环境变量变化会自动 Recreate

用户级设置（语言、深色模式、时区等）不在环境变量里，通过 Web 界面修改，或 API POST /api/users/saveUserSettings 全量提交（实测把 language 改为 zh 后 getUserSettings 回读生效）。

四、参数总览

实例级环境变量全集（源码 backend/utils/helpers.go InitSettings() 与 docker-entrypoint.sh 实查，查询日期 2026-11-01）：

另有两个非官方配置用途的变量：HTTPS_PROXY（Go 标准库 net/http 自动识别，用于修复 /api/version 出网检查，见 B2 篇 FAQ）与 compose 注入的常规变量。

五、核心参数分类详解

5.1 SECRET_TOKEN：会话的命根子

SECRET_TOKEN 是 JWT 的 HS256 签名密钥。不设置时每次启动随机生成——实测无 env 临时容器重启两次，日志打出两个不同 token：

Secret Token: HCDMvi9nB2EY6gFR1fWQdO5r4OmuPDVBAhPzKE1Gx_U=
Secret Token: jdgn-hb-IICliDG0_wV5yhw5vGAfx2TwY0eV-sv6O2Q=

后果：容器一重启，所有已登录会话的 cookie 签名校验失败，全员掉线。轮换 token 的完整实测（主容器）：

export SECRET_TOKEN=$(openssl rand -base64 32)
docker compose up -d
curl -s -b cookies.txt -w '\nhttp=%{http_code}\n' http://127.0.0.1:8137/api/users/check

Unauthorized

http=401

重新登录后恢复 http=200。因此：compose 里 ${SECRET_TOKEN} 引用务必确保 up -d 前已 export（或写 .env 文件），否则变量置空等价于随机 token（B2 篇 FAQ 11.2 的坑即源于此）。

JWT 本身结构实测（解码登录 cookie 的 payload）：

{
  "user_id": 1,
  "name": "admin",
  "derived_key": "qfZaaFYnsILnGy+LeHiDmRZO88vq4qj6YyEIxgZYbY4=",
  "exp": 1796988221
}

⚠️ 载荷中 derived_key 为明文。cookie 虽 HttpOnly，但一旦泄露（如日志、抓包）即等于泄露解密密钥材料，务必配合 HTTPS 反代使用。

5.2 加密与密钥参数（不可配置，但必须知道）

DailyTxT 的加密参数硬编码在源码里，无环境变量可改，实测从 users.json 落盘数据直接可见：

• 口令派生：Argon2id，参数 m=65536,t=5,p=6（64MB 内存、5 轮、6 并行度），落盘哈希形如：

$argon2id$v=19$m=65536,t=5,p=6$KptvrvgA8PAVTIkIjgJZrw$jgI7CtuDHocUDnrhd8Mlckvcuzfg93vpWVR6t6ebLIE

• 数据加密：ChaCha20-Poly1305 AEAD（错误路径实测回显 chacha20poly1305: bad key length）；
• 密钥层级：登录口令 → Argon2id 派生 derived key（存 JWT cookie）→ 解密用户随机 encryption key → 解密全部日记/标签/模板/设置。encryption key 以密文形式存 users.json 的 enc_enc_key 字段，永不离开服务器；
• 改密码不重加密数据：源码实测逻辑是用旧 derived key 解出 encryption key、再用新 derived key 重新封装，秒级完成；
• 备份码：POST /api/users/createBackupCodes（带当前密码）实测返回 6 个一次性码，可替代密码登录/恢复备份，仅展示一次：

{"available_backup_codes":-1,"backup_codes":["$3jv{mJyM%","9C]#XMWRo#","V[06~4Ae1~","W9{aIb!hu4","TVLD3$(W39","8h=#c2R9GP"],"success":true}

• 官方 README 明确这不是客户端端到端加密（为保留服务端全文搜索，解密发生在后端内存）。

5.3 注册与会话参数

ALLOW_REGISTRATION 默认 false。无 env 临时容器实测：

curl -s http://127.0.0.1:8142/api/users/isRegistrationAllowed

{"registration_allowed":false,"temporary_allowed":false,"until":"0001-01-01T00:00:00Z"}

curl -s -w '\nhttp=%{http_code}\n' -X POST http://127.0.0.1:8142/api/users/register \
  -H 'Content-Type: application/json' -d '{"username":"root","password":"q1w2e3r4"}'

Registration is not allowed

http=403

已关注册时管理员可临时开放 5 分钟（实测 60 秒参数）：

{"duration":60,"success":true,"until":"2026-11-01T11:22:01Z"}

LOGOUT_AFTER_DAYS 直接决定登录 cookie 的 Expires，实测对照：临时容器设 7 → Expires=Sun, 08 Nov 2026 11:38:01 GMT；主容器设 40 → Expires=Fri, 11 Dec 2026 11:38:01 GMT（均为请求时刻 + N 天）。注意这是无状态过期：GET /api/users/logout 只是清 cookie，实测登出后旧 token 在有效期内调 API 仍然成功——真正的吊销手段只有轮换 SECRET_TOKEN（见 5.1）。

5.4 存储与格式参数

DATA_PATH 默认 /data。实测临时容器设 DATA_PATH=/srv/dt 后，注册的用户数据直接落 /srv/dt/users.json，entrypoint 的 mkdir -p 与后端 MkdirAll 都会自动建目录。

INDENT 控制所有 JSON 落盘缩进（纯美观，不影响数据）。实测对照：临时容器 INDENT=2 的 users.json 为两空格缩进；主容器 INDENT=4 为四空格；默认 0 则输出压缩单行 JSON。

数据目录结构实测（注册并使用后的完整树）：

data/1/2026/11.json
data/1/settings.encrypted
data/1/tags.json
data/1/templates.json
data/users.json

• users.json：外层明文 JSON，敏感字段密文。实测字段：username、user_id、salt、password（Argon2id 哈希）、enc_enc_key（加密的加密密钥）、dailytxt_version: 2、last_seen_version: "2.6.4"、backup_codes[]；
• 1/：user_id 目录；2026/11.json 按月存日记，外层结构明文（day、files、history 骨架），文本内容密文：

"text": "SF_vjMpWEYq4hFV2vtihNXKjLIxWbYBg31pijxqFqkI2Rx1apracdJ-nu4XLkNidPgr3hG8zPOtGZ30..."

• tags.json：id/next_id 明文、name/color/icon 密文；
• settings.encrypted：整个文件即一段 base64url 密文；
• 无数据库：官方 README 原话 "No database is used"，备份 = 打包数据卷，恢复 = 还原文件。

5.5 网络与部署参数

BASE_PATH 由 docker-entrypoint.sh 用 sed 改写前端产物，实测设 /diary 后：

Using BASE_PATH: 'diary'

index.html 中 SvelteKit base 与模块导入路径被改写：

base: "/diary"
import("/diary/_app/immutable/entry/start.Dfe5nTuo.js")

PWA manifest 同步生效（/manifest.webmanifest 实测回显）：

{"name":"DailyTxT","short_name":"DailyTxT","start_url":"/diary","display":"standalone",...

⚠️ 实测确认：BASE_PATH 只影响前端静态资源与 PWA，后端 API 仍挂在 /api/ 前缀（请求 /diary/api/version 返回的是 index.html 兜底页，text/html）。反向代理需同时把 /diary 静态路径与 /api 路径正确转发。

ALLOWED_HOSTS 逗号分隔跨域白名单。为空时后端启动告警且不挂 CORS 中间件：

dailytxt: 2026-11-01 11:36:29 main.go:151: Warning: ALLOWED_HOSTS is empty, CORS will not allow any cross-origin requests

设 ALLOWED_HOSTS="http://localhost:5173,http://example.com" 后实测：白名单内 Origin 返回完整 CORS 头，白名单外 Origin 无任何 Access-Control-Allow-* 头，OPTIONS 预检同样通过：

HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: Content-Type, Authorization, Content-Disposition
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Origin: http://localhost:5173

同源部署（浏览器直接访问 nginx 端口）无需设置。

DEVELOPMENT 设 true 仅切换开发模式标记（日志可见 Development Mode: true），生产不要开。

PUBLIC_DEMO_MODE 由 entrypoint 注入前端。实测不设置时 sed 把占位符替换为空串，index.html 产生一行非法 JS：

window.DEMO_MODE = ;

页面主功能不受影响（该赋值独立于模块脚本），但建议显式设 PUBLIC_DEMO_MODE=false 消掉语法错误。

六、生产配置模板

适用场景：个人/家庭自托管（1-10 用户），1GB 内存以上小机器（实测 docker stats 常驻内存约 73MiB），日记文本 + 少量图片附件，磁盘占用见 3.2 节 free_space/disk_usage 字段。

services:
  dailytxt:
    image: phitux/dailytxt:2.6.4
    restart: unless-stopped
    volumes:
      - ./data:/data
    environment:
      - SECRET_TOKEN=${SECRET_TOKEN}   # 写入 .env，勿用明文提交版本库
      - ALLOW_REGISTRATION=false       # 首用户建好后关闭
      - ADMIN_PASSWORD=${ADMIN_PASSWORD}
      - LOGOUT_AFTER_DAYS=30
      - INDENT=2
      - PUBLIC_DEMO_MODE=false
      - BASE_PATH=/                    # 反代子路径部署时改
    ports:
      - "127.0.0.1:8137:80"            # 仅本机，由 Nginx/Caddy 反代出公网并启用 HTTPS

要点：SECRET_TOKEN 持久化是重中之重（5.1）；对外访问务必走 HTTPS（5.1 JWT 明文派生密钥）；/api/version 需出网检查更新，内网隔离环境注入 HTTPS_PROXY 或在用户设置里关闭 checkForUpdates（B2 篇 FAQ 11.1 实测）。

七、常见问题

7.1 为什么每次重建容器后所有人都掉线？ SECRET_TOKEN 没设或 compose 变量没导出，每次启动随机换签名密钥。固定 token 并确认 docker logs 里 Secret Token 稳定不变。

7.2 注册接口 403？ ALLOW_REGISTRATION 默认 false。临时开放用管理端点 POST /api/admin/open-registration（实测返回 until 时间戳，到期自动关闭）。

7.3 改了 cookie 有效期没感觉？ LOGOUT_AFTER_DAYS 只影响新登录签发的 cookie Expires；旧 cookie 仍按旧期限。且 logout 不吊销 token（5.3），全局踢人请轮换 SECRET_TOKEN。

7.4 users.json 里能看到用户名字和哈希，数据到底加密没有？ 加密的是内容层：日记文本、标签名、模板、设置全为密文（5.4 实测字段）；用户名、日期骨架、文件大小等元数据明文。这是服务端搜索能力的代价，官方 README 明确该取舍。

7.5 available_backup_codes 一直是 -1？ 实测该字段为 -1 表示未生成过备份码（createBackupCodes 成功后才会显示数量）。备份码只展示一次，丢失只能重新生成。

7.6 前端控制台报 window.DEMO_MODE = ; 语法错误？ PUBLIC_DEMO_MODE 未显式设置导致 sed 替换为空（5.5），设 false 即可。

八、参考链接

• 官方仓库 README（环境变量与加密设计，查询日期 2026-11-01）：https://github.com/PhiTux/DailyTxT
• 后端配置解析源码 backend/utils/helpers.go InitSettings()：https://github.com/PhiTux/DailyTxT/blob/main/backend/utils/helpers.go
• 镜像与 tag 列表：https://hub.docker.com/r/phitux/dailytxt/tags
• 站内姊妹篇：《DailyTxT 2.6.4 Docker Compose 部署指南》