企业官网建设流程全解析

1. 先摸清底细：iTop 与 Windows 这套组合值不值得选

1.1 iTop 到底解决什么问题，装它的人图什么

iTop 是 Combodo 出的一套开源 ITSM 系统，全称 IT Operations Portal，开源协议是 AGPL。它最核心的两块能力，一个是工单流程（事件、请求、变更、问题、服务、SLA），另一个是CMDB 配置管理数据库——也就是把服务器、应用、网络设备、数据库、机房、机柜、联系人这些资产，以及它们之间的依赖关系全部登记起来，再基于这张关系图做影响分析。很多人第一次听说它，是在需要"给公司搞一套不花钱的报修和资产管理平台"的时候。

它跟市面上那些商业 ITSM 最大的区别，是数据模型可编排。你可以在后台自己加类、加字段、改流程状态机，甚至重新排版表单。这种灵活度是有代价的：它的学习曲线比一般 PHP 应用陡得多，安装环节对运行环境的要求也比 WordPress、Discuz 那类程序挑剔。我第一次给客户部署的时候，光环境依赖就来回折腾了两天，原因不是 iTop 有多难，而是它对 PHP 扩展、字符集、目录权限这些细节卡得比较死。

它适合什么样的人？中小团队里负责 IT 运维、桌面支持、资产盘点的那位同学；或者项目交付方需要在客户内网部署一套工单系统的实施人员。它不适合只想找个"能提交表单"的轻量工具的人——那类需求用现成的看板工具就够了，上 iTop 属于杀鸡用牛刀，后续维护成本也划不来。

1.2 Windows 上跑 PHP 应用的真实体验与取舍

iTop 官方推荐的运行环境是 Linux + Apache/Nginx + PHP + MySQL/MariaDB。Windows 不是首选，但这不代表装不上。真实情况往往是：客户内网只有 Windows Server，没有独立的 Linux 虚机，安全策略也不允许随便开新系统，那就只能在 Windows 上落地。我遇到过的场景十有八九是这样——资产台账、域账号、文件共享都在 Windows 域里，再加一台 Linux 反而增加运维负担。

Windows 这条路有几个必须提前认下的现实：一是路径分隔符和大小写带来的文件权限问题，PHP 在 Windows 下写文件走的是 ACL 而不是 POSIX 权限位，你没法简单用chmod 777一劳永逸；二是服务身份问题，Apache 或 IIS 跑在哪个账户下，直接决定了它能不能写conf/、log/、data/这三个目录；三是MySQL 8 的默认认证插件在早期 PHP 版本上会直接连不上，这个坑我后面会专门讲。

除了这些，Windows 伺候 PHP 应用其实没那么糟。进程管理、计划任务、日志轮转这些运维动作，Windows 自带的工具链完全够用，而且图形化排查比在 Linux 上翻日志要直观。真正要接受的是性能上的差距——同样配置下 PHP 在 Windows 的并发表现会比 Linux 差一截，但 iTop 这种内部办公系统，日活几十上百人的规模，这点差距基本感知不到。

1.3 三条安装路线的横向对比与我的选择

在 Windows 上装 iTop，实际有三条路可走，我把它们的差异列出来，你可以对照自己的情况挑：

我自己给客户做生产部署，选的是手工组装。原因很直接：一体化包的 PHP 版本往往落后，而且它的 MySQL 配置是给通用场景调的，iTop 的max_allowed_packet、sql_mode、字符集这些参数需要单独优化；一旦上线后要升 PHP 大版本，集成包会把你逼到重装的地步。但如果只是想在本地先验证一下 iTop 到底长什么样，集成包绝对是效率最高的选择，先把东西跑通再谈优化。

这里插一句关于影响范围的判断。装 iTop 不只是装一个软件，它会牵动三件事：第一，它要接管你们的工单入口，意味着原有靠邮件、微信群报修的习惯要改，这属于流程变革，阻力往往比技术问题大；第二，CMDB 要有人维护，数据不准等于白建，得明确一个数据 owner；第三，它可能要和域账号、邮件服务器、监控系统对接，任何一个对接失败都会导致系统"半残"。所以在动手装之前，先把这三件事的边界划清楚，比装得快更重要。

2. 动手前的环境盘点：版本、目录、端口一次理清

2.1 版本兼容矩阵，别装完才发现不匹配

iTop 各版本对环境的要求差异不小，尤其是 PHP 的版本区间卡得很死。我整理了一张对照表，你按自己打算装的 iTop 版本反查环境要求：

需要特别注意两点。PHP 8.x 从 8.0 到 8.2 之间的兼容性并不完全一致，如果你选 3.1 系列，建议 PHP 落在8.0 或 8.1，这是被验证最多的组合，8.2 也支持但部分扩展的编译版本在 Windows 上要挑对 TS/NTS（线程安全/非线程安全）——Apache 模块方式加载 PHP 要用 TS 版，FastCGI 方式建议用 NTS 版，这个选错了会直接导致 Apache 启动失败。

数据库方面，MySQL 8.0 是可以用的，但它是从 8.0.4 开始把默认认证插件换成caching_sha2_password，老版本 PHP 的 mysqlnd 驱动不认这个插件，报错长得像"认证插件无法加载"。要么把 iTop 用的那个数据库账号单独改成mysql_native_password，要么确保 PHP 版本够新。这个坑我吃过一次，后面第 3 章会给出具体的建用户语句。

2.2 目录规划与磁盘分配

Windows 上装 Web 应用，最忌讳把东西散在系统盘各处。我建议按下面的结构规划，所有组件放在同一个根目录下，备份和迁移的时候整目录打包带走就行：

D:\web\ ├── apache24\ Apache 主程序 ├── php81\ PHP 运行环境 ├── mysql80\ MySQL 服务端与数据目录 ├── www\ │ └── itop\ iTop 站点根目录（解压后的文件） └── backup\ 数据库导出与配置备份

磁盘容量上给个参考值。iTop 程序本体解压后大概 200MB 左右，数据库初始数据（含测试数据）约 50MB，但如果你们把 CMDB 全量导进去、附件也用数据库存，半年内涨到 5–10GB 是很正常的。所以数据目录单独放一块盘，别和系统盘混在一起。如果条件允许，给 MySQL 的数据目录放 SSD，iTop 的仪表盘和搜索查询会明显快一截。

还有一件事容易被忽略：Windows 路径长度限制。iTop 里有不少层级很深的目录，如果你把站点放在C:\Users\某某某\Documents\...这种长路径下，解压时可能因为路径超长而丢文件。把根目录放在盘符下一级，能省掉大量莫名其妙的"文件缺失"问题。

2.3 系统层前置检查清单

动手之前把这几项跑一遍，能省下后面一半的排障时间。

端口占用检查。80 端口十有八九被 IIS 或某个占用程序占着。用下面这行命令看是谁在用：

netstat -ano | findstr :80 tasklist | findstr <上面查到的PID>

如果确实是 IIS 占着，要么给它换端口，要么让 iTop 也走 IIS（第 1.3 节的第三条路线），别指望两个服务共用一个 80。

服务账户确认。Apache 作为 Windows 服务启动时，默认跑在LocalSystem下，权限很大但不符合最小权限原则。我更推荐创建一个专用的本地账户，比如svc_web，把 Apache 服务改成用这个账户登录，然后针对性地给它 iTop 目录的写权限。查当前进程身份：

tasklist /v /fi "imagename eq httpd.exe"

防火墙与杀软。开放 80（或你自定义的端口）入站规则；另外，某些终端防护软件会拦截httpd.exe绑定端口或写文件，如果启动后立刻消失、事件日志里什么都没有，先把杀软临时放一边测一轮。

时间与时区。把服务器时区设成Asia/Shanghai，并且开启与域控或公网时间服务器同步。iTop 的 SLA 计算、工单时间戳全部依赖服务器时间，时间漂移会让 SLA 报表彻底失真，这种问题排查起来特别痛苦，因为它不会报错，只会"数字不对"。

3. 核心组件落地：Web 服务器、PHP、MySQL 的安装与调参

3.1 用一体化包快速起步的完整步骤

先把快的路走一遍，适合本地验证。以 XAMPP 为例，下载时务必选对应 PHP 版本的安装包，别用默认版本。

安装完成后，服务启动顺序有讲究：先启 MySQL，再启 Apache。反过来也行，但 MySQL 启动慢的时候 Apache 那边如果碰巧在初始化连接池容易报错，索性养成固定顺序。

接下来把 iTop 解压到D:\xampp\htdocs\itop\，注意是解压后直接把内容铺进去，别多套一层目录——很多人解压出来是itop-3.1.0\这个文件夹，直接扔进去，结果访问http://localhost/itop/显示目录列表，因为真正的入口在下一层。

最后验证 PHP 环境是否达标。把下面内容存成info.php放到htdocs下：

<?php phpinfo(); ?>

浏览器访问它，重点检查三项：PHP 版本号、Loaded Configuration File指向的php.ini路径（这决定了你改哪个文件才生效）、以及mysqli扩展是否在列表里。查完立刻删掉这个文件，它会把服务器路径、扩展版本、环境变量全暴露出去。

3.2 php.ini 里必须改的十来项参数

iTop 的安装向导会自己检测一部分配置，但有些参数它不检测，等你跑到中途才翻车。下面是必改清单，改完重启 Apache 生效：

注意：extension=这几行在 php.ini 里经常是存在的但被注释掉了（前面有分号）。别新增一行，直接把原来的分号去掉。多个 php.ini 同时存在（比如 PHP 目录一份、Apache 目录一份）是新手最常踩的坑，以phpinfo()里显示的Loaded Configuration File为准。

如果你打算用命令行跑 iTop 的定时任务，命令行加载的 php.ini 和 Apache 加载的可能不是同一个。用php --ini确认一遍，否则会出现在网页里好好的，一到计划任务就报扩展缺失的怪事。

3.3 MySQL 8 的建库建用户与两个经典坑

iTop 安装向导可以自己建库，但我不建议。手工建库能把字符集和账号权限一次性定死，省得后面改。用管理员账号连上 MySQL，执行：

CREATE DATABASE itop DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; CREATE USER 'itopuser'@'localhost' IDENTIFIED WITH mysql_native_password BY '换成你的强密码'; GRANT ALL PRIVILEGES ON itop.* TO 'itopuser'@'localhost'; FLUSH PRIVILEGES;

第一坑就是IDENTIFIED WITH mysql_native_password这句。MySQL 8 默认用caching_sha2_password，PHP 7.4 以下的 mysqlnd 驱动不认，连接时报"Authentication plugin 'caching_sha2_password' cannot be loaded"。加上这句就绕过去了。如果你的 PHP 是 8.0 以上、且编译时用的 mysqlnd 比较新，这句可以省，但为了少踩坑，加上没有坏处。

第二坑是sql_mode。MySQL 5.7 起默认开启ONLY_FULL_GROUP_BY，某些 iTop 的报表查询在老版本上会因此报错。如果你用的是 iTop 3.x，一般不需要动；如果碰到Expression #N of SELECT list is not in GROUP BY clause这类报错，就把这一段从 sql_mode 里去掉：

[mysqld] sql_mode = "STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION"

顺便把这两个参数调一下，iTop 同步大批量数据时会用到：

[mysqld] max_allowed_packet = 64M innodb_buffer_pool_size = 1G

max_allowed_packet太小会导致导入大附件或执行大数据量 SQL 时直接断连，报错信息是"MySQL server has gone away"，看着吓人，其实就是包太大被拒了。

4. iTop 本体安装：从解压到向导跑完的完整流程

4.1 安装包获取与落地位置

iTop 的安装包在 SourceForge 和 Combodo 官网上都能下到，文件名形如itop-3.1.x-xxxx.zip。下载后解压，把内容放到 Web 根目录下的itop文件夹里。放好之后确认一下目录结构，根目录下应该直接能看到setup、conf、env-production、webservices、pages、index.php这些，如果看到的是一个孤零零的同名文件夹，说明多套了一层。

站点别名（Alias）在 Apache 里配好，让它能通过http://你的服务器/itop/访问：

Alias /itop "D:/web/www/itop" <Directory "D:/web/www/itop"> Options FollowSymLinks AllowOverride All Require all granted </Directory>

AllowOverride All这句很关键，它决定了 iTop 自带的.htaccess防护文件会不会生效。这个后面还会讲到。

4.2 Windows 目录权限与 .htaccess 失效问题

这是 Windows 部署 iTop 最容易卡住的地方。Linux 上一个chmod -R 775解决的事，在 Windows 上要明确两件事：谁需要写、写哪些目录。

先确认 Apache 运行身份（前面讲过tasklist /v），假设是svc_web这个账户，那么需要写权限的目录是：

用icacls批量赋权最省事：

icacls "D:\web\www\itop\conf" /grant "svc_web:(OI)(CI)M" /T icacls "D:\web\www\itop\log" /grant "svc_web:(OI)(CI)M" /T icacls "D:\web\www\itop\env-production" /grant "svc_web:(OI)(CI)M" /T icacls "D:\web\www\itop\data" /grant "svc_web:(OI)(CI)M" /T

(OI)(CI)表示继承到子文件和子目录，M是 Modify 权限。别图省事直接给Everyone:F，那是给自己挖坑——iTop 的配置文件里存着数据库明文口令，权限放开等于把口令写在公告栏上。

再说.htaccess的问题。iTop 在env-production、conf、log、data这些目录下都放了.htaccess用来禁止直接访问。这些文件在 Apache 上要靠AllowOverride All生效，在 IIS 上则完全不生效。如果你走的是 IIS 路线，必须在 IIS 管理器里手工给这几个目录加"请求筛选"规则，或者干脆把它们移到网站根目录之外。我见过不止一次，因为没处理这个，导致任何人访问http://host/itop/conf/production/config-itop.php就能直接下载到数据库口令。

4.3 安装向导每一步在问什么，怎么填

访问http://你的服务器/itop/setup/，向导会依次问下面这些内容，我按实际顺序说明每一项的填法和判断依据。

第一步是环境检测。它会列出 PHP 版本、必需扩展、目录可写性的检测结果。任何一项红叉都不能往下走，硬走的后果是装到一半崩掉，留下一个半残的数据库，清理起来比重装还麻烦。这里的红叉通常对应两种情况：扩展没开（回去改 php.ini），目录不可写（回去改 ACL）。

第二步是许可协议。AGPL，勾选同意即可。要注意的是，AGPL 对"通过网络提供服务"的场景有源码开放要求，如果这套系统是给外部客户用的，建议先让法务看一眼，别等上线后才发现合规问题。

第三步是数据库连接参数。填主机（一般是localhost）、端口（3306）、数据库名itop、用户名itopuser、密码。填完它会尝试连接，如果报"Unknown database"就说明库没建；报认证插件错误就是第 3.3 节讲的caching_sha2_password问题。

第四步是管理员账号。这里要设的是 iTop 自己的超级管理员（默认用户名admin），和数据库账号完全是两回事。密码强度按公司规范来，但别用默认密码直接投产，iTop 的默认账号是公开信息，公网可访问的实例几小时内就会被扫描到。

第五步是选择安装模式。全新安装选"Install a new instance"；如果检测到已有实例，它会给升级选项。这一步千万别选错，选错了会覆盖现有数据。

第六步是数据库初始化。它会把表结构建起来并导入初始数据。这一步最耗时间，视机器性能，一到五分钟不等。如果中途超时白屏，先去看max_execution_time和max_input_time，再看数据库里是不是已经建了一半的表——如果是，把库 drop 掉重建，别试图续着装。

第七步是选择要加载的模块。它会让你勾选要启用的功能集，比如 ITIL 工单、CMDB 资产、服务目录等。我的建议是全部勾上，因为后面禁用某个模块比重装要麻烦得多。额外的模块只是多几张表，不会拖慢系统。

向导跑完后会提示你删除setup目录。这一步必须做，setup目录留着等于留了个后门，任何人都能重跑安装向导。

4.4 装完立刻要做的四项加固

第一项，删掉或重命名 setup 目录。这是 iTop 官方文档里反复强调的，也是最容易被跳过的。

第二项，把conf/production/config-itop.php设为只读。iTop 后台有个开关可以控制配置文件的只读状态，打开它之后，任何试图改配置的动作都会被拒绝。这样即使有人拿到了 Web 后台权限，也没法通过改配置来执行任意代码。

第三项，关掉display_errors。安装期的开启是为了看报错，上线后必须关，否则一旦出现异常，页面会把服务器绝对路径、数据库名甚至部分 SQL 全打印出来。

第四项，改掉 admin 的默认用户名。改成什么不重要，重要的是别叫 admin。iTop 允许创建同名用户，你可以新建一个管理员账号，把默认的删掉或禁用。

5. 中文化、时区与通知：让系统真正能用起来

5.1 中文语言包与字符集一致性

iTop 自带简体中文语言包，登录后进"管理"→"用户"→ 自己的账号，把语言改成"简体中文"就行。如果改完发现部分菜单还是英文，那是语言包翻译不完整的正常现象，不是装错了。

真正要盯的是字符集一致性。这个问题分三层：数据库层、表层、连接层。数据库层在你建库时已经定了utf8mb4，表层是 iTop 自己按库的字符集建的，连接层由 iTop 的配置文件控制。三层必须一致，任何一层用了latin1或utf8（注意 MySQL 里的utf8是三字节的，不是真正的 UTF-8，要认准utf8mb4），中文就会出现问号或乱码。

验证办法很简单：新建一个工单，标题里输入几个生僻字和 emoji（emoji 是四字节字符，正好能测出utf8和utf8mb4的差别），提交后看数据库里存的是不是原样。如果 emoji 变成问号，说明某处还是utf8。这时候用这条语句查出元凶：

SELECT TABLE_NAME, TABLE_COLLATION FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'itop' AND TABLE_COLLATION NOT LIKE 'utf8mb4%';

哪些表不是utf8mb4，就单独改：

ALTER TABLE 表名 CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

5.2 时区、URL 与 config-itop.php 里值得手工改的项

conf/production/config-itop.php是 iTop 的核心配置文件，改之前先备份，改完记得把只读开关关掉再改，改完再打开（第 4.4 节讲的）。

几个值得手工调的地方。app_root_url要设成实际的访问地址，如果服务器有域名就填域名，填错了会导致邮件里的链接点不开、附件下载 404。时区相关的配置要和 PHP 的date.timezone保持一致，两处不一致会出现"日志时间是对的，工单时间差 8 小时"这种精神分裂的现象。另外allow_password_change之类的安全开关，按公司密码策略决定开不开。

还有一个容易被忽略的点：如果服务器前面挂了反向代理或者负载均衡，iTop 拿到的客户端 IP 会是代理的 IP，导致审计日志里所有操作都来自同一个地址。这时候要在配置里加上信任的代理地址列表，让它从X-Forwarded-For里取真实 IP。

5.3 邮件通知与计划任务的落地配置

iTop 的邮件通知有两个方向：发出去（工单状态变更通知）和收进来（把收到的邮件转成工单）。发送用 SMTP，在配置文件里填服务器地址、端口、账号密码、加密方式。这里有个坑：公司邮箱服务器如果用了自签名证书，PHP 的 curl 或 stream 会直接拒绝连接，报 SSL 验证失败。折中办法是把证书导入 Windows 的受信任根证书存储，而不是简单地把验证关掉——关掉验证意味着邮件内容在传输中可被篡改。

收邮件转工单需要 iTop 的邮件收集器，它在后台有个定时任务去轮询邮箱。Windows 上实现定时的方式是计划任务，调用 iTop 根目录下的cron.php：

"D:\web\php81\php.exe" "D:\web\www\itop\cron.php" --auth_user=admin --auth_pwd=你的密码 --param_file="D:\web\www\itop\conf\production\config-itop.php"

这条命令挂到"任务计划程序"里，设成每 5 分钟跑一次。注意几个细节：--auth_user和--auth_pwd用的是 iTop 里的管理员账号，不是数据库账号；--param_file一定要显式指定，否则命令行环境找不到配置会直接失败；任务计划里要勾"不管用户是否登录都要运行"，否则服务器一重启、没人登录，任务就不跑了。

提示：把密码明文写在计划任务的命令行里并不安全，同机器上任何用户都能通过任务计划界面看到。更稳妥的做法是单独建一个专用的 cron 账号，只给它最小权限，密码泄露时影响可控。

6. 上线之后的运维节奏：备份、升级与监控

6.1 备份策略：数据库 + 配置 + 附件

iTop 的数据分三块，备份必须全覆盖，只备数据库是不够的。

第一块是数据库，这是主体。用mysqldump导出，注意几个参数：

"D:\web\mysql80\bin\mysqldump.exe" -u itopuser -p^ --default-character-set=utf8mb4^ --single-transaction^ --routines --triggers^ --set-gtid-purged=OFF^ itop > "D:\web\backup\itop_20250101.sql"

--single-transaction保证导出时数据一致，不用锁表；--default-character-set=utf8mb4防止导出文件本身是乱码；--routines --triggers把存储过程和触发器一起带走，iTop 的部分功能依赖它们。恢复的时候如果报 GTID 相关的错，--set-gtid-purged=OFF就是解药。

第二块是conf/production/config-itop.php，这里面存着数据库连接串、邮件配置、各种开关。丢了它，就算数据库恢复出来，系统也连不上。

第三块是附件。iTop 默认把工单附件存在数据库里，这种模式下数据库备份就等于附件备份。但 iTop 也支持把附件存到文件系统，如果你启用了这个模式，data/目录必须纳入备份范围，而且要和数据库备份保持时间点一致，否则恢复后会出现"工单记录在、附件没了"的情况。

自动化的话，写个 bat 脚本，用for /f生成日期格式的文件名，挂到任务计划里每天凌晨跑一次。保留策略我给个参考：日备保留 14 天，周备保留 8 周，月备保留 12 个月。更重要的是定期做恢复演练，备份文件躺在那里不代表能用，我见过太多"备份了三年，真要恢复时发现压缩包损坏"的案例。

6.2 升级 iTop 的正确姿势

iTop 的升级有一条硬规则：不支持跨大版本跳升。从 2.7 直接到 3.1 是不行的，必须 2.7 → 3.0 → 3.1 逐级走。这不是官方保守，是因为每个大版本之间的数据模型变更脚本是按序设计的，跳过中间版本会导致某些字段迁移丢失。

升级的流程大致是：先在测试环境完整演练一遍，确认流程和插件都正常；然后备份生产库和配置文件；把新版本文件解压到新目录（别原地覆盖）；改配置文件指向原有数据库；访问setup目录，向导会检测到已有实例并给出升级选项；跑完升级脚本后，对比一下升级前后的记录数、用户数、关键对象数量。

升级前必做的两件小事：把config-itop.php的只读开关关掉，否则升级脚本写不进去；确认所有第三方扩展（如果有）有对应的新版本，扩展不兼容是升级失败的头号原因。

6.3 用 Windows 计划任务托管 iTop 的定时作业

iTop 需要定时的活儿主要有三类：邮件轮询、异步任务的批量执行、以及缓存清理。都通过cron.php触发，区别只是参数。

计划任务的配置有几个坑要避开。"起始于"这一栏必须填，填成 iTop 的根目录，否则cron.php里的相对路径引用会全部失效；账户要用有权限跑 PHP 的那个，别用SYSTEM，SYSTEM账户虽然权限大，但它访问不到网络共享，邮件轮询如果是连远程邮件服务器会失败；日志重定向，把 cron 的输出写到文件里，方便排查：

"D:\web\php81\php.exe" "D:\web\www\itop\cron.php" ... >> "D:\web\www\itop\log\cron.log" 2>&1

日志要定期清，iTop 的 cron 日志会一直追加，几个月下来能涨到几百兆。写个每周清理的脚本，或者用 Windows 的日志轮转工具处理。

7. 排障实录：安装阶段最容易翻车的九个点

7.1 五百错误、白屏与页面残缺

500 Internal Server Error是最笼统的报错，光看页面什么信息都没有，必须去翻日志。日志位置是 Apache 的error.log和 PHP 自己的error_log，后者的位置在 php.ini 里配。现场做法是临时把display_errors打开、error_reporting设成E_ALL，刷新页面就能看到具体的文件和行号。查完记得改回去。

白屏但 HTTP 状态是 200，说明 PHP 执行过程中静默死掉了，最常见的原因是memory_limit不够或者某个必需扩展没加载。把memory_limit直接调到-1（不限制）测一轮，如果好了就是内存问题，再往下找到底是哪个操作吃内存。

页面出来了但样式全丢、按钮点不动，一般是静态资源路径不对。检查app_root_url配置，以及 Apache 的 Alias 是否配对了目录。如果 URL 里带上了多余的端口或者路径前缀，CSS 和 JS 会请求到 404，浏览器控制台的 Network 面板里一堆红色请求，一眼就能看出来。

中文显示成问号或方块，回到第 5.1 节的三层字符集检查。还有一种情况是页面本身的编码声明不对，这个在 iTop 正常安装的情况下不会出现，但如果有人手工改过模板文件就可能发生。

7.2 数据库连接与字符集报错

"Authentication plugin 'caching_sha2_password' cannot be loaded"，MySQL 8 的认证插件问题，按第 3.3 节的语句重建用户。

"MySQL server has gone away"，多半是单次传输的数据包超过了max_allowed_packet，把它调大；也可能是wait_timeout太短，长连接被服务端掐断了。

"Access denied for user"，注意检查用户的主机部分。MySQL 的用户是user@host组合，itopuser@localhost和itopuser@127.0.0.1是两个不同的用户。iTop 配置里写的是127.0.0.1就去建对应 host 的用户。

"Table doesn't exist"，如果是在安装过程中出现的，大概率是向导跑到一半中断了，数据库处于半成品状态。把库 drop 掉重建，重跑向导，不要试图手工补表。

7.3 常见问题速查表

8. 几个只有真跑过才知道的细节

先说一个 ACL 的隐形坑。用icacls赋权之后，如果后来你手工在log目录里新建了子文件夹，新文件夹不会自动继承之前设的权限——注意，(OI)(CI)的作用是让权限在创建时被继承，但如果你是用管理员身份在资源管理器里新建的，创建者是你而不是svc_web，继承规则可能因为父目录的 ACL 被后续修改而失效。稳妥做法是把svc_web加进log目录的"所有者"里，或者每次批量赋权时加/T递归整个目录树。

再说安装向导的一个反直觉行为。它在第六步建表时，如果中途失败，不会自动回滚。我第一次遇到的时候试图重跑向导，结果它检测到已有表就报冲突，只能手工清理。所以只要向导中途崩了，第一反应应该是DROP DATABASE itop然后重建，而不是重试。

还有一个关于性能的实测感受。iTop 的仪表盘在加载时会执行一批聚合查询，如果 CMDB 里有几万个配置项，第一次打开首页可能要等十几秒。这不是装错了，是数据量到了。解决办法是给itop库的几个大表加上合适的索引，具体加哪些字段，去log目录里找到慢查询日志，按实际的WHERE条件来加，别凭感觉乱加——索引加多了会拖慢写入，工单创建变慢比仪表盘慢更让人难受。

最后留个后续扩展的思路。iTop 支持 REST 接口（webservices/rest.php），如果你们公司有监控系统，可以把告警自动创建成工单；如果有资产管理系统，可以做 CMDB 数据同步。这些对接都不复杂，但一定要先在测试环境验证接口权限和字段映射，别直接在生产环境连调——我曾经因为字段名拼错，一口气往生产库写了三千条空工单，清理花了一整个下午。

我的经验是，iTop 在 Windows 上的部署难度，八成集中在环境准备和权限这两个环节，真正装 iTop 本身反而是最简单的部分。把第 2 章的检查清单老老实实过一遍，把第 4.2 节的 ACL 和.htaccess问题提前解决掉，整个过程通常半天能搞定。剩下那半天，留给数据初始化和人员培训更划算。