Atheos v601 配置参数详解

目标：把 config.php 里 13 个常量与 data/ 下 5 类运行态文件讲清楚，并给出 8 项在本站点的实测结果，读完能自己改配置、自己验证。测试环境：Ubuntu 26.04.1 LTS（x86_64）、Apache/2.4.65、PHP 8.1.34，站点根目录 /var/www/html，Atheos v601（.version 文件为 {"version":601}），实测日期 2026-10-27，演示账号 admin / q1w2e3r4。站内前置阅读：《Atheos v601 介绍与选型指南》、《Ubuntu 22.04 安装 Atheos v601 指南》、《Atheos v601 部署指南》。

一、配置体系：一个常量文件 + 一组 JSON 运行态

Atheos 没有数据库，全部状态落在文件系统里。理解这一点，后面所有参数才有意义：

/var/www/html/
├── config.php          # 唯一的配置入口（安装向导生成）
├── common.php          # 加载 config.php、初始化 session/时区/安全头
├── controller.php      # JSON 接口总路由（按 target 分发到 components|plugins）
├── components/         # 内置功能模块（user/filemanager/codegit/install...）
├── libraries/          # 前端依赖（carbon/echo/flux/...）
├── plugins/            # 第三方插件目录（出厂只有 README.md）
├── data/               # ★ 运行态：用户、项目、日志、缓存
├── workspace/          # ★ 用户可见的项目根目录
├── theme/              # 主题 CSS 与 theme.json
├── languages/          # 20 个语言包（含 cn.json）
└── favicons/           # blue / green / red 三套图标

加载链路的真实顺序（源码实证）：

1. 页面入口 index.php、接口入口 controller.php 都先 require_once("common.php")；
2. common.php 的 Common::initialize() 在第 54 行加载 config.php；
3. 随后才处理 LIFETIME（session 生命周期）、补全未定义的路径常量、设置时区、兜底 HEADERS；
4. 第 95 行判断 AUTH_PATH 是否存在并 require_once（外部认证挂载点）。

这带来两个必知的副作用：

• 配置常量缺失不会报错，会被默认值兜底。common.php 里 THEME、TIMEZONE、LANGUAGE、DEVELOPMENT、HEADERS、PLUGINS 等都有 if (!defined(...)) 兜底，所以写了拼错的常量名时页面照常打开、配置却不生效——排查时必须以「常量探针」确认，而不是看页面有没有报错。
• WEBROOT 是硬编码：common.php 第 60 行写着 define("WEBROOT", "/var/www/html/");。站点部署在别的前缀（例如 /var/www/atheos）时必须同步改这一行，否则前端静态资源会 404，而 BASE_URL 改了也没用。

运行态文件清单（data/）

二、参数总表

config.php 由安装向导按模板生成，本表的「模板默认」取自 components/install/process.php 第 111 行起的 $configData 模板，「本站实测」取自当前站点 php -r 探针输出。

后三个 URL 常量在 config.php 的「DO NOT EDIT CONFIG BELOW」分界线以下，属于出厂写死的对外服务地址：内网离线环境下更新检查与插件市场必然失败，但这不影响 IDE 主体功能，按官方注释保持原样即可。

三、路径类参数：改之前先看清权限

路径常量的默认值都从 BASE_PATH 派生，因此不要在 config.php 里单独改 DATA/WORKSPACE 的写法，而是直接覆盖定义。实测探针命令（在站点根目录执行，只读取常量，不产生副作用）：

cd /var/www/html
php -r 'require "config.php";
foreach(["BASE_PATH","BASE_URL","THEME","LIFETIME","TIMEZONE","DEVELOPMENT","PLUGINS","DATA","WORKSPACE"] as $c)
  printf("%-12s = %s\n", $c, defined($c) ? var_export(constant($c), true) : "UNDEFINED");'

实测输出（当前站点）：

BASE_PATH    = '/var/www/html'
BASE_URL     = '127.0.0.1:8130'
THEME        = 'dark blue'
LIFETIME     = false
TIMEZONE     = 'Asia/Shanghai'
DEVELOPMENT  = false
PLUGINS      = '/var/www/html/plugins'
DATA         = '/var/www/html/data'
WORKSPACE    = '/var/www/html/workspace'

把工作区挪到大盘（例如 /srv/atheos/workspace）的正确做法只有两步：

// config.php —— 追加在 HEADERS 之后、分界线之前
define("WORKSPACE", "/srv/atheos/workspace");

# 权限：Web 进程用户必须可读写，本站为 www-data
sudo chown -R www-data:www-data /srv/atheos/workspace
sudo -u www-data test -w /srv/atheos/workspace && echo WRITABLE

注意两点：

• WORKSPACE 与 DATA 都是目录常量，不是 URL；写 URL 会让文件管理器直接报「项目不存在」。
• 项目列表在 data/projects.db.json，改 WORKSPACE 后原有项目仍按名映射到新根目录下的同名子目录，不存在就新建——所以迁移时要先 rsync 目录内容，再改常量顺序不能反。

四、站点标识与外观：DOMAIN / THEME

DOMAIN 实测

DOMAIN 只影响页面标题，源码是 index.php 中的 echo(DOMAIN . " | ") 拼接。把 DOMAIN 由空改为 QuZuoTest 后：

curl -s http://127.0.0.1:8130/ | grep -o '<title>[^<]*</title>'
# 改前：<title>Atheos IDE</title>
# 改后：<title>QuZuoTest | Atheos IDE</title>

适合同一域名下挂多套实例（如 dev | Atheos IDE、prod | Atheos IDE）时一眼区分环境。

THEME 实测

THEME 的值被原样写进 <html> 的 class：

curl -s http://127.0.0.1:8130/ | grep -o '<html lang="en" class="[^"]*"'
# <html lang="en" class="dark blue"

也就是说主题名直接成为 CSS 类名（dark blue 带空格，对应两个类 dark、blue）。本站出厂 theme/ 只有一套默认主题，theme/theme.json 记录 name: Atheos、category: dark、version: 4.0.0。换主题不能只改常量：要么把新主题解包进 theme/ 并覆盖 main.min.css，要么保持默认。图标侧另有 favicons/blue、favicons/green、favicons/red 三套可选，由 templates/favicons.php 引用。

语言

languages/ 下实测 20 个包：bg cn cz de de_original en es fr hu it ja nl pl pt ro ru sk sr sv tr。中文即 cn.json，登录时 POST language=cn 生效，前端语言选择结果存入用户数据；data/cache/i18n_en.cache.php 是按语言生成的解析缓存，改语言包后删掉对应缓存文件即可强制重载。

五、会话生命周期与时区：两个最容易被忽略的常量

LIFETIME：false 与数字的差别是「关浏览器是否掉登录」

common.php 第 56–58 行只做一件事：LIFETIME !== false 时执行 ini_set("session.cookie_lifetime", LIFETIME)。实测对照：

# LIFETIME = false（出厂）
curl -s -D- -o /dev/null -X POST http://127.0.0.1:8130/controller.php \
  -d 'action=authenticate&target=user&username=admin&password=q1w2e3r4&language=en' | grep -i set-cookie
# Set-Cookie: <sid>=...; path=/

# LIFETIME = 7200
# Set-Cookie: <sid>=...; expires=Tue, 27-Oct-2026 13:52:39 GMT; Max-Age=7200; path=/s

false 时 Cookie 无 expires，属浏览器会话级，关窗口即失效，安全性更好；设为 7200 后带 Max-Age，适合长任务场景，但共用终端风险随之上升。注意 0 不是「永久」，与 false 语义相同。

TIMEZONE：日志时间戳跟着它走，PHP 系统时区不跟

common.php 第 77–82 行先 date_default_timezone_set(TIMEZONE)，异常才退回 UTC。实测把 TIMEZONE 由 Asia/Shanghai 改成 UTC 后立即登录一次：

# sites time: date -u  ->  Tue Oct 27 11:52:40 UTC 2026
grep lastLogin data/users.json
# 改前（Asia/Shanghai）："lastLogin": "2026-10-27 19:52:09"
# 改后（UTC）：          "lastLogin": "2026-10-27 11:52:40"

两边与 date -u 完全对齐，证明 data/users.json、data/log/access.log 的时间戳全部由该常量决定。跨时区团队建议统一 UTC，与主机 date 输出一致，排障时不会算错 8 小时；国内单站点保持 Asia/Shanghai 可读性更好。改完记得让用户重新登录一次，lastLogin 才会以新时区落盘。

六、认证、密码策略与「注册开关」

AUTH_PATH：外部认证的唯一挂载点

config.php 里 AUTH_PATH 默认被注释。取消注释并指向一个存在的 PHP 文件后，common.php 第 95 行会在初始化阶段 require_once 它，可实现「复用公司 LDAP/SSO 会话」。该文件必须自行完成登录态判定并写入 $_SESSION["user"]，否则 Atheos 侧仍是未登录。本站未启用，属未实测项。

密码：只有 bcrypt，没有复杂度策略

源码实证（components/user/class.user.php）：

• 写入：password_hash($password, PASSWORD_DEFAULT)，PHP 8.1 下为 bcrypt，data/users.json 中哈希形如 $2y$10$...（cost=10）；
• 校验：password_verify($password, $user["password"])，失败返回 451 Invalid password.；
• 全文件没有长度、字符集、重复字符等任何强度校验，安装向导 components/install/process.php 同样只做 password_hash。也就是说 1 也能设为密码，密码强度必须由部署方在流程上约束。

账号字段实测（data/users.json）：

{
    "admin": {
        "password": "$2y$10$KDMAMQWs9bLIV9tkEdKIP.S5HcgmuqQub7m9.p9maC7WMb5m38tqW",
        "resetPassword": false,
        "activeProject": "demo",
        "creationDate": "2026-10-27 09:42:55",
        "lastLogin": "2026-10-27 18:15:49",
        "permissions": ["configure", "read", "write"],
        "userACL": "full"
    }
}

• permissions 三档：configure（改系统配置）、read、write；新建账号默认只有 read+write（class.user.php 第 133 行），改配置能力需手动授予。
• userACL：full 表示可访问全部项目，否则是逗号分隔的项目名白名单。
• resetPassword：为 true 时下次登录强制改密，忘记密码的兜底手段之一。

注册开关：不存在

components/user/controller.php 的 action 全集为 authenticate / password / create / delete / changePermissions / ...，其中 create 走管理员权限校验；源码与安装向导中均无 register、signup 之类入口（grep -rn "register|signup" components/user/ 无匹配）。结论：Atheos v601 没有自助注册，账号一律由管理员在「设置 → 用户」中创建，或直接编辑 data/users.json（改完须保证 JSON 合法与哈希格式正确）。

HEADERS：只在页面入口生效

模板写入 8 条安全头。实测页面入口 GET /：

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Referrer-Policy: no-referrer
Feature-Policy: sync-xhr 'self'
Access-Control-Allow-Origin: *

而 JSON 接口 POST /controller.php 的响应里只剩 X-Frame-Options 与 X-Content-Type-Options（这两条来自 Web 服务器配置，不是 PHP），Strict-Transport-Security、Referrer-Policy、Feature-Policy 等没有出现——因为 HEADERS 的输出写在 index.php 里，controller.php 不执行这段。凡是要求「全站统一安全头」的合规场景，必须在 Web 服务器层补齐，不能只依赖这个常量。另注：Access-Control-Allow-Origin: * 是宽放行，生产环境应改为具体域名，.htaccess 侧的限制见《Ubuntu 22.04 安装 Atheos v601 指南》「安全加固」一节。

七、上传限制与日志

Atheos 自身不设上传上限，实际上限由 PHP 配置决定。本站 php -i 实测（/usr/local/etc/php/conf.d/atheos.ini 注入）：

要放开到 200M，必须三处同改，只改一个会出现「表单提交成功但文件没落盘」的静默失败：

upload_max_filesize = 200M
post_max_size = 200M
memory_limit = 512M
max_execution_time = 300

session.gc_maxlifetime 也要一起抬高，否则用户挂着长任务时服务端 session 先被回收，表现为「刷新后要求重新登录」。

日志方面：

tail -3 data/log/access.log
# @2026-10-27 17:43:06:	{admin} logged in
# @2026-10-27 18:15:49:	{admin} logged in
# @2026-10-27 19:52:09:	{admin} logged in

格式固定为 @<时间>\t{<操作者>} <动作>，改密、改权限都会落一条。日志不做轮转，长期运行需外部 logrotate 接手；data/ 整体属于敏感目录，Web 服务器必须禁止直读（.htaccess/Nginx deny），否则 users.json 可被直接下载。

八、DEVELOPMENT：一个常量，两种资源加载方式

实测同一页面在两种模式下的 <script> 数量：

curl -s http://127.0.0.1:8130/ | grep -c '<script'
# DEVELOPMENT = false -> 3
# DEVELOPMENT = true  -> 20

false 时走合并产物：

<script src="public/libraries.min.js"></script>
<script src="public/modules.min.js"></script>
<script src="components/user/init.js"></script>

true 时逐文件加载，便于改前端即时生效与断点调试：

<script src="libraries/carbon.js"></script>
<script src="libraries/echo.js"></script>
<script src="libraries/flux.js"></script>
<script src="libraries/global.js"></script>
<script src="libraries/icons.js"></script>
<script src="libraries/myth.js"></script>
...

首屏请求数从 3 涨到 20，生产环境务必保持 false；排查「改了 CSS/JS 不生效」时，先确认是否误开该模式（开了以后浏览器缓存的是散文件，而不是 public/*.min.js）。

九、配置变更标准流程

# 1) 备份（单文件配置尤其需要）
cp config.php /root/config.php.$(date +%Y%m%d%H%M)

# 2) 改完先过语法
php -l config.php
# No syntax errors detected in config.php

# 3) 常量探针确认真的生效（不要只看页面能不能开）
php -r 'require "config.php"; var_dump(TIMEZONE, LIFETIME, WORKSPACE);'

# 4) 重载 Web 服务并回归
sudo systemctl reload apache2
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8130/
curl -s -D- -o /dev/null -X POST http://127.0.0.1:8130/controller.php \
  -d 'action=authenticate&target=user&username=admin&password=q1w2e3r4&language=en'

第 3 步是最有价值的一步：common.php 会给缺失常量兜底默认值，页面「看起来正常」完全不能证明配置被读到；只有 var_dump 出你写的值才算生效。

十、排障实录

十一、小结与下一步

• 必改项：WORKSPACE（大盘）、LIFETIME（按安全要求）、TIMEZONE（按团队）、HEADERS 的 Access-Control-Allow-Origin（收窄）。
• 不要改：UPDATEURL/MARKETURL/GITHUBAPI（出厂服务地址，离线环境失败不影响主体）。
• 不存在：注册开关（无自助注册）、密码复杂度策略（只有 bcrypt）。
• 必须在服务器层补齐：JSON 接口的安全头、data/ 目录的禁读、上传限制的 ini 覆盖。

配置面到此为止。同专栏另三篇分别覆盖选型、裸机安装、Compose 部署，建议按顺序阅读；下一篇进入接口与二次开发层。