Docker Compose 编排 LNMP 部署 WordPress 实践-北京尧图网络

1. 先把为什么要这么干想明白LNMPLinux Nginx MySQL PHP这套组合在家里跑个小站、在公司做个内部测试环境几乎是默认选项。但凡是手动装过一遍的人都知道这套东西装起来不难难的是下次再装一遍——PHP 扩展版本对不上、MySQL 字符集忘了改、Nginx 的fastcgi_pass指向了个不存在的 socket随便一个环节出岔子半天就没了。我最早给一个内部团队搭 WordPress 演示站光是编译 PHP 扩展就折腾了两个晚上最后一次是在另一台机器上复现结果又踩了同样的坑。从那之后我基本不再在宿主机上直接装 LNMP 了全部转到 Docker 里跑用一份 compose 文件把四个服务的版本、端口、挂载目录、依赖关系全部锁死换台机器只要把目录拷过去两条命令就能起来。这篇内容讲的就是这条路用 Docker 部署一套 LNMP并在上面把 WordPress 跑起来。它解决的核心问题是环境可复现和组件解耦——Nginx 只管静态资源和转发PHP-FPM 只管执行 PHPMySQL 只管数据WordPress 只是个放在挂载目录里的代码包任何一个组件要升级、要替换、要回滚都不影响其他三个。适合的读者范围其实挺宽刚接触容器、想找个完整例子练手的新手手上有一堆小站要管、不想每次都手工装环境的运维以及想给客户快速搭演示站、又不想污染自己机器的外包同学。哪怕你之前只跑过docker run hello-world照着做一遍也能通。下面我按为什么这么选 → 环境怎么准备 → 编排文件怎么写 → WordPress 怎么调 → 出问题怎么排的顺序讲中间会穿插我自己踩过的坑和一些参数选择上的取舍理由你可以直接抄但建议先看懂再抄。2. 方案选型为什么是 Compose 而不是一堆 run 命令2.1 传统手动部署到底痛在哪手动装 LNMP 的流程大概是装系统包 → 加第三方源 → 装 Nginx → 装 MySQL 并跑mysql_secure_installation→ 装 PHP 及一堆扩展 → 改php.ini→ 改nginx.conf→ 配www.conf里的user和listen→ 建库建用户 → 传代码 → 调权限。这一长串里版本耦合和隐式状态是两个最大的雷。版本耦合是说 Nginx 和 PHP-FPM 之间靠 socket 通信PHP 升级换了个 socket 路径Nginx 那边不改就 502隐式状态是说系统里装过的东西、改过的配置文件、加过的源全都没有记录第二次装的时候你根本不知道自己上次动了什么。容器化把这两个问题都摁住了。镜像里自带的运行时环境是确定的你在 compose 里写php:8.2-fpm那它永远是 8.2不会因为宿主机某次系统更新变成别的版本所有配置通过挂载文件注入配置文件本身就在你的项目目录里是可见的、可版本管理的。我现在的习惯是每个站点一个目录里面放docker-compose.yml、nginx/、php/、mysql/、html/整个目录扔进 Git换机器一拉就能重建。2.2 单容器一体化镜像的问题市面上有把 Nginx PHP MySQL 全塞进一个镜像的方案甚至还有带 Web 面板的。这类镜像上手快但我个人不太推荐用在稍微要认真一点的地方原因有三个。第一是违背了容器的单一职责原则。一个容器里跑三个守护进程日志混在一起某个进程挂了整个容器就不可用排查的时候你分不清是 PHP 崩了还是 MySQL 把内存吃满了。第二是扩展和升级受限。你想给 PHP 加个gd或者imagick扩展一体镜像里没预装你得自己写 Dockerfile 从基础镜像重新构建反而比分开更麻烦。第三是数据安全。数据库和代码放在同一个容器的可写层里容器一删数据全没除非你事先挂载但很多人第一次用根本没意识到这一点。分开跑就没这些事。MySQL 单独一个容器数据卷挂到宿主机目录容器删了数据还在PHP-FPM 单独一个容器想加扩展就基于官方镜像写三行 DockerfileNginx 单独一个容器配置改错了直接docker compose restart nginx不影响数据库。代价是服务之间要配网络通信但这个代价用 Compose 的自定义网络可以完全消化掉。2.3 服务拓扑与通信方式的设计我给这套东西定的拓扑很简单四个服务一个自定义 bridge 网络只有 Nginx 对外暴露 80/443其他三个服务只在网络内部可见。WordPress 代码目录同时挂给 Nginx 和 PHP-FPM 两个容器这是关键——Nginx 需要直接读静态文件图片、CSS、JSPHP-FPM 需要读 PHP 源码执行两边看到的必须是同一份文件否则就会出现页面能打开但样式全丢或者PHP 文件被当静态文件下载这类怪问题。通信路径是这样的浏览器请求到 Nginx → Nginx 判断是静态文件就直接返回 → 是.php结尾的就通过fastcgi_pass php:9000转发给 PHP-FPM 容器这里php是服务名Compose 内置的 DNS 会把它解析成容器 IP→ PHP 执行时通过服务名mysql:3306连数据库 → 结果原路返回。整个过程 Nginx 和 PHP 之间走的是 FastCGI 协议不是 HTTP所以fastcgi_pass后面跟的是主机名加端口不是 URL。注意服务名在 compose 里就是主机名但只有同一个自定义网络内的容器才能互相解析。默认的bridge网络不支持按服务名解析必须显式声明一个networks块这一点新手极容易漏。3. 环境准备与镜像选型3.1 宿主机需要满足什么条件宿主机本身要求不高一台 2 核 4G 的机器跑这套东西绰绰有余WordPress 站点如果访问量不大2G 内存也能撑。系统层面建议用较新的发行版内核 4.x 以上。需要确认的只有几件事Docker Engine 装好建议 20.10 以上Compose V2 插件可用现在都是docker compose而不是老式的docker-compose以及 80 端口没有被别的服务占用。检查命令很简单跑一下看看版本docker version docker compose version ss -tlnp | grep -E :80|:3306第三条命令是看端口占用如果 80 被系统的 Nginx 或 Apache 占了起来之后会报bind: address already in use。这种情况要么先停掉宿主机的 Web 服务要么把映射端口改成8080:80。我一般建议直接把宿主机的 Web 服务卸掉避免两套东西打架也能省点内存。还有一个容易被忽略的点文件系统。MySQL 的数据目录挂在宿主机上如果宿主机用的是某些网络文件系统或者有奇怪的大小写敏感设置可能出现表名找不到的问题。常规的 ext4、xfs 都没问题如果你是在某些虚拟化平台的共享目录里跑建议把 MySQL 数据目录换成 Docker 命名卷named volume性能和数据一致性都更稳。3.2 四个镜像怎么挑版本镜像选型这块我给个明确的建议别追最新追稳定且互相兼容的组合。组件推荐镜像版本选择理由Web 服务器nginx:1.24-alpine或nginx:stable-alpinealpine 体积小启动快stable 标签保证不会突然跳到不兼容的大版本PHPphp:8.2-fpmDebian 基础8.2 是目前兼容性最广的版本主流插件都支持用 Debian 基础而非 alpine是因为很多 PHP 扩展在 alpine 上要额外装编译工具反而更麻烦数据库mysql:8.0或mariadb:10.11MySQL 8.0 是长期支持版本如果机器内存紧张MariaDB 更轻兼容性也好应用wordpress:6.x-php8.2-fpm官方镜像已经内置了 WordPress 代码和必要的 PHP 扩展省掉自己下载解压的步骤这里有个细节要展开说一下为什么 PHP 用 Debian 版而不是 alpine 版。alpine 用的是 musl libc体积确实小一半但 WordPress 生态里很多插件的扩展比如gd、intl、zip在 alpine 上装的时候要现场编译编译又需要gcc、make、autoconf一堆工具镜像构建时间翻好几倍最后体积也没小多少。Debian 版虽然大一点但docker-php-ext-install装扩展是预编译好的几秒钟完事。我早期用 alpine 踩过一次imagick编译失败卡了快一小时从那之后就固定用 Debian 版了除非是纯静态资源服务才用 alpine。MySQL 8.0 有个坑要注意默认认证插件是caching_sha2_password老版本的 PHP 客户端连不上。不过现在 PHP 8.x 的mysqli和pdo_mysql都支持这个插件一般不会有问题如果你用的是更老的 PHP 版本需要在 MySQL 配置里加default-authentication-pluginmysql_native_password。3.3 目录结构先定好动手写配置之前先把目录结构规划清楚后面所有挂载路径都基于这个结构改起来才不会乱。我习惯这么组织/opt/site-demo/ ├── docker-compose.yml ├── nginx/ │ ├── conf.d/ │ │ └── default.conf │ └── nginx.conf ├── php/ │ ├── php.ini │ └── Dockerfile ├── mysql/ │ ├── conf.d/ │ │ └── my.cnf │ └── data/ # 数据库数据权限要特别注意 ├── logs/ │ ├── nginx/ │ └── php/ └── html/ # WordPress 代码根目录这个结构的好处是职责按目录切分谁出问题看哪个目录一目了然。logs单独拎出来是因为容器内日志如果不挂出来容器删了日志就没了排查问题时很被动。mysql/data放宿主机目录方便直接备份直接tar打包就行但要注意宿主机上的mysql用户uid 通常是 999必须对这个目录有读写权限否则容器启动会报Permission denied。提示如果宿主机上已经有同名的mysql用户uid 可能不是 999会冲突。稳妥的做法是容器里不指定 user让 MySQL 镜像自己处理或者先用docker run --rm mysql:8.0 id看一下实际 uid 再改目录属主。4. Compose 编排文件怎么写才不出事4.1 整体骨架与网络声明先把骨架搭出来。这份文件我调过很多次最终版本在下面每个块后面我都会解释为什么这么写。services: nginx: image: nginx:1.24-alpine container_name: lnmp-nginx ports: - 80:80 volumes: - ./html:/var/www/html:ro - ./nginx/conf.d:/etc/nginx/conf.d:ro - ./nginx/nginx.conf:/etc/nginx/nginx.conf:ro - ./logs/nginx:/var/log/nginx depends_on: - php networks: - lnmp restart: unless-stopped php: build: ./php container_name: lnmp-php volumes: - ./html:/var/www/html - ./php/php.ini:/usr/local/etc/php/php.ini:ro - ./logs/php:/var/log environment: - TZAsia/Shanghai depends_on: - mysql networks: - lnmp restart: unless-stopped mysql: image: mysql:8.0 container_name: lnmp-mysql command: - --character-set-serverutf8mb4 - --collation-serverutf8mb4_unicode_ci - --default-time-zone08:00 environment: MYSQL_ROOT_PASSWORD: change_me_root MYSQL_DATABASE: wordpress MYSQL_USER: wpuser MYSQL_PASSWORD: change_me_wp TZ: Asia/Shanghai volumes: - ./mysql/data:/var/lib/mysql - ./mysql/conf.d:/etc/mysql/conf.d:ro networks: - lnmp restart: unless-stopped networks: lnmp: driver: bridge几个关键点说明一下。nginx挂载html目录时加了:ro只读因为 Nginx 不需要往代码目录写东西只读挂载能防止某些情况下 Nginx 误写文件导致权限混乱——WordPress 上传的文件是 PHP 写的跟 Nginx 无关。反过来 PHP 容器挂载html必须是可写的不然上传附件、装插件、更新主题全都会失败。depends_on只保证启动顺序不保证依赖服务已经就绪。也就是说php容器启动时mysql可能还在初始化PHP 连不上数据库。这个问题在 WordPress 首次安装时特别明显页面会报Error establishing a database connection。解决办法有两个一是加healthcheck让 Compose 等 MySQL 真正可用二是在 PHP 侧做重试。我一般用 healthcheck更干净mysql: # ... 其他配置 healthcheck: test: [CMD, mysqladmin, ping, -h, localhost, -pchange_me_root] interval: 10s timeout: 5s retries: 5 start_period: 30s然后在php的depends_on里改成条件形式depends_on: mysql: condition: service_healthy这样就能确保 PHP 启动时数据库已经能响应 ping 了。start_period给 30 秒是给 MySQL 首次初始化留时间第一次启动要建表、初始化系统库慢的话可能要 20 多秒。4.2 Nginx 配置里最容易写错的几行Nginx 的default.conf是整个流程里最容易出问题的地方我把它单独拆出来讲。核心配置长这样server { listen 80; server_name localhost; root /var/www/html; index index.php index.html; location / { try_files $uri $uri/ /index.php?$args; } location ~ \.php$ { fastcgi_pass php:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } location ~ /\.ht { deny all; } client_max_body_size 64m; }逐行解释一下。root /var/www/html必须和容器里挂载的路径完全一致也就是 compose 里./html:/var/www/html的右侧。try_files $uri $uri/ /index.php?$args是 WordPress 伪静态的关键它保证了/about/这种固定链接能被正确转给 PHP 处理而不是返回 404。如果漏了这一行装完 WordPress 之后除了首页其他页面全是 404。fastcgi_pass php:9000这里的php就是 compose 里的服务名Compose 的网络会把服务名解析成容器 IP。千万不要写127.0.0.1:9000那指的是 Nginx 容器自己PHP-FPM 不在那个容器里写了必然 502。同理fastcgi_param SCRIPT_FILENAME不能漏漏了 PHP 会报File not found因为 PHP 不知道要执行哪个文件。client_max_body_size 64m也要加默认是 1m上传大一点的图片或者装主题包直接 413。这个值和 PHP 的upload_max_filesize、post_max_size要配合设置光改一边没用。还有location ~ /\.ht { deny all; }这行防止.htaccess之类文件被直接访问下载属于安全加固加着不亏。4.3 PHP 容器怎么构建与调参PHP 官方镜像默认没装 WordPress 常用的一些扩展所以要自己写个 Dockerfile 基于它加装。文件放在php/DockerfileFROM php:8.2-fpm RUN apt-get update apt-get install -y --no-install-recommends \ libpng-dev libjpeg-dev libfreetype6-dev libzip-dev \ docker-php-ext-configure gd --with-freetype --with-jpeg \ docker-php-ext-install -j$(nproc) gd mysqli pdo_mysql zip opcache \ apt-get clean \ rm -rf /var/lib/apt/lists/* RUN pecl install redis docker-php-ext-enable redis这里装的是 WordPress 最常用的几个扩展gd用于图片缩略图处理mysqli和pdo_mysql用于数据库连接zip用于装插件和主题时解压opcache用于加速 PHP 执行redis是可选的如果打算做对象缓存可以装。docker-php-ext-configure gd那行不能省GD 库的 freetype 和 jpeg 支持必须显式配置否则处理某些格式的图会失败表现为上传图片后缩略图是全黑的。构建方式是在 compose 目录下跑docker compose build php第一次会花几分钟之后有缓存就快了。php.ini里最重要的几项upload_max_filesize 64M post_max_size 64M memory_limit 256M max_execution_time 300 date.timezone Asia/Shanghai opcache.enable 1 opcache.memory_consumption 128memory_limit给 256M 是因为装某些大插件比如页面构建器类的在 128M 下会内存溢出白屏。max_execution_time调到 300 秒是为了应对导入大文件或者批量处理。这几项和 Nginx 的client_max_body_size保持一致上传限制才能生效。注意PHP-FPM 的www.conf里默认listen 127.0.0.1:9000如果你基于官方镜像改官方镜像里的默认配置已经是listen 9000监听所有地址一般不用动。但如果自己换基础镜像一定要改成0.0.0.0:9000或者9000否则 Nginx 连不进来。5. WordPress 上线与后续调优5.1 首次安装流程与 wp-config 的关键项四个容器都起来之后浏览器访问http://服务器IP会进入 WordPress 安装向导。数据库信息填 compose 里配的数据库名wordpress、用户名wpuser、密码对应MYSQL_PASSWORD、数据库主机填mysql:3306。这个主机名是最容易填错的地方很多人习惯性填localhost但localhost在 PHP 容器里指的是容器自己根本没有 MySQL 服务会直接报连接失败。安装向导走完会生成wp-config.php如果你提前手动放了一份向导会跳过创建步骤直接用你的。我一般选择手动放因为需要改几个关键项define(DB_NAME, wordpress); define(DB_USER, wpuser); define(DB_PASSWORD, change_me_wp); define(DB_HOST, mysql:3306); define(DB_CHARSET, utf8mb4); define(DB_COLLATE, ); define(AUTH_KEY, 这里填随机串); // ... 其他七个密钥 $table_prefix wp_; define(WP_DEBUG, false); define(WP_HOME, https://your-domain.com); define(WP_SITEURL, https://your-domain.com); define(FS_METHOD, direct); if (!defined(ABSPATH)) { define(ABSPATH, __DIR__ . /); } require_once ABSPATH . wp-settings.php;几个关键项解释。DB_HOST必须是mysql:3306理由同上。八个安全密钥AUTH_KEY到NONCE_SALT一定要填随机值空着或者用默认值会让登录 Cookie 可预测是个实打实的安全隐患可以用官方提供的生成接口拿一串。FS_METHOD设为direct是为了跳过 FTP 凭据验证直接让 WordPress 用文件系统方式装插件、更新核心容器环境下这是必要的否则后台点更新会弹出一个要 FTP 账号的页面。WP_HOME和WP_SITEURL写死的好处是防止数据库里的域名和你实际访问的域名不一致导致跳转错乱。如果你打算先从 IP 访问、后面再绑域名这两行可以暂时不写等域名定下来再加上或者改用define(WP_HOME, http:// . $_SERVER[HTTP_HOST])这种动态写法但动态写法在多域名场景下会有隐患正式站建议写死。5.2 文件权限这个坎必须过容器跑 WordPress 最常见的错误就是权限。宿主机上html目录的属主是你的登录用户容器里 PHP-FPM 以www-datauid 33运行两者对不上结果就是上传失败、装插件要输入 FTP 账号、后台提示无法写入文件。处理方式有几种我推荐的是把宿主机目录属主改成和容器内一致# 先查容器内 www-data 的 uid docker compose exec php id www-data # 假设输出 uid33(www-data) gid33(www-data) sudo chown -R 33:33 ./html sudo find ./html -type d -exec chmod 755 {} \; sudo find ./html -type f -exec chmod 644 {} \;目录给 755、文件给 644 是标准配置不要图省事给 777那等于给所有进程写权限是个安全隐患。wp-config.php建议单独收紧到 640只有所有者能改。上传目录wp-content/uploads需要写权限上面这套设置已经满足了。如果你不想动宿主机目录的属主比如宿主机上还有别的服务在用这个目录可以在 compose 里给 php 服务指定user: 1000:1000换成你宿主机用户的 uid让容器以你的身份运行。这个方案的好处是不用sudo chown缺点是如果容器内需要写系统目录会失败PHP-FPM 的 pid 文件默认在/run下可能要额外处理。两种方案各有取舍我一般在新机器上用第一种在老机器上被其他服务绑着的时候用第二种。5.3 HTTPS、反代与上传限制的联动如果前面还有一层反向代理比如云厂商的负载均衡或者宿主机上另有一个 Nginx 做入口WordPress 会识别不出 HTTPS导致后台登录跳转死循环、混合内容告警。解决办法是在wp-config.php里加if (isset($_SERVER[HTTP_X_FORWARDED_PROTO]) $_SERVER[HTTP_X_FORWARDED_PROTO] https) { $_SERVER[HTTPS] on; }同时在 Nginx 的fastcgi_params里把HTTP_X_FORWARDED_PROTO透传过去。更简洁的做法是在 Nginx 配置里直接设fastcgi_param HTTPS on;不过这需要 Nginx 自己就终止了 TLS如果 TLS 是在更外层终止的还是得靠透传 header。上传限制的联动前面提过这里给个完整的对应关系层级配置项建议值Nginxclient_max_body_size64mPHPupload_max_filesize64MPHPpost_max_size64MPHPmemory_limit256MPHPmax_execution_time300这四个值要一起改只改一个的话小文件能传、大文件失败而且失败时的报错信息往往指向别处很容易误判。改完记得重启 php 和 nginx 两个容器改配置不重启是不生效的。6. 踩坑记录与排查思路实录6.1 502、404、500 分别指向哪里这三种错误码在 LNMP 环境里的含义非常明确按码定位能省很多时间。502 Bad Gateway基本都是 Nginx 连不上 PHP-FPM。可能原因PHP 容器没起来docker compose ps看一下状态、fastcgi_pass的主机名写错必须是服务名php、PHP-FPM 没监听正确地址、或者 PHP 容器 OOM 被杀。排查顺序是先看docker compose ps再看docker compose logs php最后进 Nginx 容器ping php确认网络通不通。404 Not Found有两种情况。一种是 Nginx 层面的 404说明文件确实不存在检查root路径和挂载是否正确另一种是 WordPress 层面的 404页面显示的是 WordPress 的模板这种情况基本就是伪静态没配try_files那行漏了或者写错了。500 Internal Server Error最麻烦因为它什么都可能是。第一反应看 PHP 错误日志./logs/php/下如果有PHP Fatal error就能直接定位如果日志里什么都没有多半是 Nginx 的fastcgi_param少配了PHP 拿不到SCRIPT_FILENAME进程直接退出。还有一种情况是wp-config.php语法错误比如少个分号也会 500 但日志里可能只有一行PHP Parse error。6.2 数据库连接失败的几种典型场景WordPress 报 Error establishing a database connection 时先别急着改配置按这个顺序查现象可能原因处理方式刚启动时连不上过一会好了MySQL 还在初始化加 healthcheck 或用depends_on条件等待一直连不上日志报Access denied用户名密码不对核对 compose 里的MYSQL_USER/MYSQL_PASSWORD和wp-config.php是否一致报Unknown database库名不对或库没建MYSQL_DATABASE只在首次初始化时生效如果数据目录已有数据新加的库不会自动创建报Cant connect to MySQL server主机名或网络不对DB_HOST必须是mysql:3306进 php 容器ping mysql验证报The server requested authentication method unknown认证插件不兼容MySQL 8 用caching_sha2_password老 PHP 需降级或改插件最后一行那个坑值得多说一句。MYSQL_DATABASE、MYSQL_USER这些环境变量只在数据目录为空时生效也就是只在第一次启动时建库建用户。如果你后来改了 compose 里的密码重启容器是不会改数据库里实际密码的得进容器用 root 手动ALTER USER。我见过有人改完 compose 密码发现还是连不上折腾半天才想起来这回事。6.3 白屏、上传失败与插件装不上的处理白屏页面完全空白状态码 200九成是 PHP 内存溢出或者致命错误。把WP_DEBUG设为true再在wp-config.php里加define(WP_DEBUG_LOG, true)错误会写到wp-content/debug.log打开看最后一行是什么。如果是Allowed memory size exhausted就调大memory_limit如果是某个插件报错直接进容器把插件目录改名就能恢复。上传失败分两种。一种是文件传不上去报超过最大上传大小这就是前面说的四个值没对齐另一种是传上去了但显示不出来缩略图裂开这通常是gd扩展没装好或者uploads目录没写权限docker compose exec php php -m | grep gd确认扩展在不在。插件装不上、提示输入 FTP 账号就是FS_METHOD没设成direct或者文件权限不对导致 PHP 无法写wp-content目录。两者的区别如果设了direct还是提示 FTP那一定是权限问题按 5.2 节的方法改属主。实操心得改完任何配置之后别只重启单个容器就想当然。Nginx 改配置要docker compose restart nginxPHP 改php.ini要重启 php 容器改了 compose 文件本身则要docker compose up -d它会重建有变化的容器。我吃过一次亏改完php.ini只重启了 nginx结果调了半天以为配置没生效。6.4 备份与迁移的顺手做法这套结构最大的好处之一是备份简单。数据库备份一条命令docker compose exec mysql mysqldump -u root -p wordpress backup.sql代码和上传文件直接打包html目录配置文件全在 compose 目录里跟代码一起进 Git。恢复的时候反过来先起 mysql 容器导入 sql再把html目录放回去docker compose up -d就完事。迁移到另一台机器也是同样的流程唯一要注意的是镜像版本要一致因为 MySQL 8.0 的数据目录不向下兼容 5.7反过来也一样跨大版本迁移必须先 dump 再导入不能直接拷数据目录。我在小团队里推这套方案的时候通常会写一个backup.sh放根目录把上面几条命令包一下加个日期后缀配合定时任务每天跑一次省得每次手动敲。最后分享一个我自己的习惯这个 compose 目录我从来不在生产机器上直接改都是本地改好、docker compose config验证语法、在测试机上跑一遍确认没问题再同步上去。容器化最值钱的地方就是环境一致但前提是你得把它当成代码来管而不是当成一个跑起来就不管了的黑盒。

Docker Compose 编排 LNMP 部署 WordPress 实践

相关推荐

C++继承中的访问权限控制详解

Flink与Pandas处理海量CSV数据的性能对比与优化

JSP智能停车场管理系统全栈开发实践

更多资讯

PCB设计规范深度解析：从网络表到布局布线的工程机制与电磁学原理

数码摄影中深度信息丢失的原因与还原技术

Java工程师AI应用开发指南：LangChain4j从入门到生产实践

操作系统内存管理第十七章答案精讲：地址转换、多级页表与TLB计算题解析

工业机器人标定技术：从基础原理到前沿应用

手机GUI Agent双通道感知：无障碍树与投屏像素融合方案

今日更新

基于YOLOv11的石油泄漏智能检测系统开发实践

AI行业变局：合规、Mod化与上下文管理的实战启示

计算机视觉与AI原生应用融合的技术实践

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？