QQ农场源代码解析：实时社交游戏架构与定时任务设计

简介：这份QQ农场HTML源代码面向Web前端初学者与对社交游戏实现机制感兴趣的开发者，提供了一套可运行、可拆解的农场经营类网页游戏核心逻辑与界面实现，帮助读者理解HTML结构、CSS样式与JavaScript交互如何协同完成播种、采摘、翻地等操作。资源包共9个文件，以jpg与png图片素材为主，用于作物、工具与界面元素展示，另含1个html主页面、1个db数据文件及1个bak备份文件，压缩包约115KB，体量轻便，适合本地快速打开研究。目前已有2144人学习下载，说明其在同类学习资料中具备一定参考价值。通过阅读源码，读者可掌握用div、img、button搭建农场布局的方法，理解CSS选择器控制生长动画与按钮反馈的技巧，并学习JavaScript监听点击事件、校验种子数量、更新金币与作物状态的完整流程，为后续开发小型Web游戏打下基础。

1. 从一份“QQ农场源代码”里能挖出什么：不只是偷菜，而是一套完整的实时社交游戏架构

很多人第一次搜“QQ农场源代码”，脑子里想的可能是找一份能直接跑起来的怀旧小游戏，重温当年定闹钟偷菜的感觉。但如果你真拿到过一份相对完整的农场类游戏源码，会发现它远不止是种菜收菜那么简单——它本质上是一套带定时任务、状态同步、排行榜和社交互动的轻量级实时系统。我最初接触这类代码，是想搞清楚“作物成熟时间到了，服务器怎么知道该通知谁”这个问题，结果顺着代码一路看下去，发现它把定时器管理、数据持久化、防作弊校验和前端渲染全串在了一起。这篇文章适合两类人：一是想通过一个具体项目理解服务端定时逻辑和状态同步的开发者，二是想自己搭一个类似玩法Demo但不知道从哪下手的人。接下来我会按“先看懂结构，再跑通最小闭环，最后处理坑”的顺序，把这份源码里真正值得复用的东西拆开讲。

2. 先拆结构再动手：农场源码的四个核心模块与数据流

2.1 为什么不能直接读业务逻辑，要先画数据流

拿到一份农场类源码，最忌讳的就是从第一个文件开始逐行读。这类项目通常包含前端渲染、网络通信、业务逻辑、数据存储四层，如果直接扎进业务代码，很容易被各种状态判断绕晕。我一般会先找三个东西：入口文件、数据表结构、定时任务注册的地方。入口文件告诉你服务怎么启动，数据表结构告诉你哪些状态需要持久化，定时任务注册的地方则决定了“作物成熟”这个核心事件是怎么被触发的。以常见的Node.js实现为例，入口通常是app.js或server.js，数据表里一定会有user_land（用户地块）和crop_config（作物配置）两张表，定时任务则可能藏在schedule/目录下或者直接用setInterval写在某个service里。先把这三处找到，再回头看业务逻辑，效率会高很多。

2.2 四个模块的职责边界与常见目录结构

一份典型的农场源码，不管是用PHP、Node.js还是Java写的，基本都会拆成下面四个模块。理解它们的边界，比记住具体函数名重要得多。

配置模块是只读的，改它不影响运行中的状态；地块状态模块是读写最频繁的，也是并发问题的高发区；定时模块决定了系统的实时感；交互接口模块则是前端直接调用的地方。把这四层分开看，后面排查问题时就能快速定位是配置写错了、状态没更新、定时没跑还是接口参数传错了。

2.3 用一条最小数据流验证理解是否正确

光看目录还不够，我习惯用一条具体的数据流来验证自己是否真的理解了结构。假设用户A在1号地种下胡萝卜，成熟时间设为2小时。这条数据流会经过以下步骤：

// 1. 接口层接收种植请求，校验参数 // routes/farm.js router.post('/plant', async (req, res) => { const { userId, landIndex, cropId } = req.body; // 校验作物是否存在、地块是否空闲 const crop = cropConfig[cropId]; if (!crop) return res.status(400).json({ error: '作物不存在' }); // 2. 状态层写入种植记录，记录当前时间戳 const plantTime = Date.now(); await landService.plant(userId, landIndex, cropId, plantTime); // 3. 计算成熟时间，写入定时任务表或内存队列 const matureTime = plantTime + crop.growTime * 1000; await scheduleService.addTask(userId, landIndex, matureTime); res.json({ ok: true, matureAt: matureTime }); });

这段代码里最关键的是plantTime和matureTime两个时间戳。plantTime用于计算当前处于哪个生长阶段，matureTime则决定定时任务什么时候触发。很多新手会直接把成熟时间存成“剩余秒数”，结果服务器一重启就全乱了。正确做法永远是存绝对时间戳，展示时再换算成剩余时间。另外注意scheduleService.addTask这一步，如果用的是内存队列，重启会丢任务；如果用的是数据库轮询，就要考虑扫描频率和性能的平衡。我一般会建议用Redis的有序集合（ZSET）来存成熟时间戳，既能持久化，又能按时间范围快速查询。

2.4 跑通最小闭环：种下一颗种子到收获的完整命令

理解数据流之后，下一步就是实际跑起来。假设你拿到的是一个Node.js + SQLite的简化版源码，可以按下面的步骤操作。先安装依赖并初始化数据库：

# 安装依赖 npm install # 初始化数据库表结构（假设源码里带了init.sql） sqlite3 farm.db < init.sql # 启动服务，默认监听3000端口 node app.js

服务启动后，用curl模拟一次完整的种植到收获流程：

# 1. 种植：用户1在0号地种下作物101 curl -X POST http://localhost:3000/api/plant \ -H "Content-Type: application/json" \ -d '{"userId":1,"landIndex":0,"cropId":101}' # 2. 查询地块状态，确认种植时间和成熟时间 curl http://localhost:3000/api/land?userId=1 # 3. 如果作物成熟时间已到，调用收获接口 curl -X POST http://localhost:3000/api/harvest \ -H "Content-Type: application/json" \ -d '{"userId":1,"landIndex":0}'

这里有几个参数需要根据源码里的配置调整：cropId对应config/crops.js里的键名，landIndex从0开始还是从1开始要看数据库设计，userId通常需要先通过注册接口创建。如果收获接口返回“作物未成熟”，先检查服务器时间和你本地时间是否一致，再检查matureTime的计算是否用了秒而不是毫秒。这个最小闭环跑通之后，你就有了一个可以调试的基础环境，后面加偷取、加好友互动、加排行榜都是在它上面扩展。

3. 定时任务与状态同步：农场源码里最容易翻车的两个地方

3.1 为什么轮询扫描比精确到秒的定时器更可靠

很多人在设计“作物成熟通知”时，第一反应是给每个作物起一个setTimeout，到点就触发。这个方案在单机、少量用户时没问题，一旦用户量上去或者服务重启，就会变成灾难。我踩过的坑是：用setTimeout管理了上万个定时器，结果Node.js的事件循环被拖慢，而且服务一重启所有定时器全丢，用户的地块永远停在“种植中”。后来改成轮询扫描，虽然看起来“笨”，但可靠性高得多。具体做法是每隔固定时间（比如30秒）扫一次数据库或Redis，找出所有matureTime <= 当前时间且状态为“种植中”的地块，批量更新为“可收获”。这个间隔可以根据业务精度调整，农场类游戏对秒级精度要求不高，30秒到1分钟完全够用。

// schedule/harvest.js const SCAN_INTERVAL = 30 * 1000; // 30秒扫描一次 async function scanMatureLands() { const now = Date.now(); // 从Redis ZSET中取出所有成熟时间小于等于当前时间的任务 const matureTasks = await redis.zrangebyscore('mature_tasks', 0, now); if (matureTasks.length === 0) return; // 批量更新地块状态为“可收获” const pipeline = redis.pipeline(); for (const task of matureTasks) { const { userId, landIndex } = JSON.parse(task); pipeline.hset(`land:${userId}`, landIndex, 'mature'); pipeline.zrem('mature_tasks', task); } await pipeline.exec(); console.log(`[harvest] 处理了 ${matureTasks.length} 个成熟地块`); } // 启动轮询 setInterval(scanMatureLands, SCAN_INTERVAL);

这段代码的关键参数是SCAN_INTERVAL，设得太短会增加数据库压力，设得太长用户会觉得“成熟了怎么还不能收”。我一般会把它设成作物最短生长周期的十分之一左右。另外注意zrangebyscore和zrem要放在同一个pipeline里，避免扫描到但删除失败导致重复处理。如果用的是纯数据库方案，就把Redis操作换成SELECT ... WHERE mature_time <= ? AND status = 'growing'加批量UPDATE，记得加索引。

3.2 状态同步：前端倒计时和服务端状态怎么对齐

农场类游戏的前端通常会在本地跑一个倒计时，显示“还有2小时3分成熟”。这个倒计时如果完全依赖前端计算，用户改系统时间或者切后台再回来，就会和服务端状态不一致。我见过最离谱的情况是用户把手机时间调到明天，然后截图说“我的菜早就熟了”。解决这个问题的原则是：前端倒计时只做展示，所有状态判断以服务端为准。具体做法是，前端每次进入农场页面时，先调一次/api/land拉取所有地块的plantTime和matureTime，然后用服务端返回的时间戳减去本地时间戳，得到一个偏移量，后续倒计时都用本地时间 + 偏移量来计算。这样即使本地时间不准，展示出来的剩余时间也是对的。

// 前端状态同步示例 async function syncLandStatus(userId) { const res = await fetch(`/api/land?userId=${userId}`); const data = await res.json(); // 计算服务端与本地的时间偏移 const serverTime = data.serverTime; const localTime = Date.now(); const timeOffset = serverTime - localTime; // 渲染每个地块 data.lands.forEach(land => { if (land.status === 'growing') { const remainMs = land.matureTime - (Date.now() + timeOffset); if (remainMs <= 0) { renderMature(land); } else { renderGrowing(land, remainMs); } } }); }

这里serverTime需要服务端在每次响应里带上，不要用HTTP头里的Date，那个精度和时区处理起来更麻烦。另外timeOffset只在页面加载时算一次，如果用户停留时间很长，可以每隔几分钟重新同步一次。这个方案不能完全防止作弊，但能保证正常用户看到的状态是一致的。

3.3 偷取功能的并发问题：两个用户同时收一块地怎么办

偷菜是农场类游戏的核心玩法，也是并发问题最集中的地方。假设用户B去偷用户A的菜，同时用户A自己也点了收获，如果代码写成“先查状态，再判断，再更新”，两个请求同时进来就会都查到“可收获”，然后都执行更新，导致一份作物被收了两次。我早期写的代码就犯过这个错，后来用Redis的原子操作或者数据库的行锁来解决。以Redis为例，可以用WATCH加事务，或者直接用Lua脚本保证判断和更新在一个原子操作里。

-- steal.lua：原子化偷取操作 -- KEYS[1] = land hash key, ARGV[1] = landIndex, ARGV[2] = thiefId local status = redis.call('HGET', KEYS[1], ARGV[1]) if status ~= 'mature' then return 0 -- 不可偷取 end -- 标记为已偷取，并记录偷取者 redis.call('HSET', KEYS[1], ARGV[1], 'stolen:' .. ARGV[2]) return 1

这个Lua脚本在Redis里执行时是原子的，不会出现两个请求同时通过status == 'mature'判断的情况。如果用的是关系型数据库，可以用UPDATE land SET status = 'stolen' WHERE id = ? AND status = 'mature'，然后检查受影响行数是否为1。关键原则是：状态判断和状态更新必须在同一个原子操作里完成，不能分开写。

4. 避坑与排查：农场源码落地时最常遇到的五个问题

4.1 作物成熟时间计算错误，总是差几个小时

现象：用户种下作物后，前端显示的成熟时间和预期差了好几个小时，有时候甚至显示负数。原因：最常见的是时间单位混用，JavaScript的Date.now()返回毫秒，但配置里写的growTime可能是秒，直接相加就会得到错误结果。另一个原因是时区处理不当，服务端用UTC时间，前端用本地时间，没有做转换。解决：统一所有时间戳为毫秒，配置里的生长时间如果是秒，乘以1000后再用。服务端返回时间戳时统一用Date.now()，不要返回格式化字符串。前端展示时用new Date(timestamp)自动处理时区。

4.2 服务重启后所有定时任务丢失

现象：服务重启后，之前种下的作物永远停在“种植中”，不会变成“可收获”。原因：定时任务存在内存里，比如用setTimeout或者内存数组管理，进程一退出就全没了。解决：把成熟时间持久化到Redis的ZSET或数据库表里，服务启动时先扫描一遍所有未完成的任务，重新注册。如果用的是Redis，记得开启AOF或RDB持久化。我一般会在服务启动的init函数里加一段“恢复未完成任务”的逻辑，确保重启后状态不丢。

4.3 偷取接口被恶意刷，一块地被偷几十次

现象：日志里发现同一个用户对同一块地调用了大量偷取请求，每次都能成功。原因：偷取接口没有做幂等校验，或者校验逻辑有漏洞，比如只检查了“是否成熟”，没检查“是否已被偷过”。解决：在偷取成功后立即把地块状态改为stolen，并记录偷取者ID。后续请求进来先检查状态，如果不是mature就直接拒绝。另外可以加频率限制，比如同一用户对同一地块每秒最多请求一次。如果用的是Lua脚本方案，原子性本身就能防止重复偷取。

4.4 数据库连接数暴涨导致服务无响应

现象：用户量稍微上来一点，服务就变得很慢，最后直接无响应，日志里全是“too many connections”。原因：每次请求都新建数据库连接，没有用连接池，或者连接池配置的max值太小。解决：检查数据库连接池配置，Node.js里常用mysql2或pg，都有连接池参数。connectionLimit一般设成10到20，acquireTimeout设成10秒左右。另外检查代码里有没有忘记release连接的地方，尤其是用了事务之后。我习惯在开发阶段就把连接池的max设小一点，比如5，这样一旦有连接泄漏很快就能发现。

4.5 前端倒计时和服务端状态不一致，用户投诉“偷不了”

现象：用户看到前端显示“可收获”，但点偷取时提示“作物未成熟”。原因：前端倒计时是基于本地时间算的，用户本地时间比服务端快了几分钟，导致前端提前显示成熟。解决：按3.2节的方案，用服务端返回的serverTime计算偏移量。另外可以在偷取接口返回失败时，把最新的地块状态一起返回，前端收到后立即刷新显示。这样即使有短暂不一致，用户也能马上看到正确状态。

5. 从能跑到好用：给农场源码加一个可验证的防作弊校验

5.1 为什么收获接口需要二次校验

最小闭环跑通之后，很多人会直接把这个Demo部署出去。但农场类游戏有一个特点：收获和偷取都涉及虚拟资产，一旦被刷，整个经济系统就崩了。我见过一个案例，有人写了个脚本每秒调用收获接口，因为服务端只判断了“是否成熟”，没有校验“这块地是不是这个用户的”，结果他把别人的菜全收了。所以收获接口至少要做两层校验：第一层是身份校验，确认请求的用户ID和地块所有者一致（偷取除外）；第二层是时间校验，服务端重新计算当前时间是否大于等于matureTime，不能信任前端传来的任何时间参数。

// 收获接口的二次校验 router.post('/harvest', async (req, res) => { const { userId, landIndex } = req.body; // 1. 查询地块信息 const land = await landService.getLand(userId, landIndex); if (!land) return res.status(404).json({ error: '地块不存在' }); // 2. 校验所有者 if (land.ownerId !== userId) { return res.status(403).json({ error: '无权操作' }); } // 3. 服务端重新计算成熟时间，不信任前端 const now = Date.now(); if (now < land.matureTime) { return res.status(400).json({ error: '作物未成熟', matureAt: land.matureTime }); } // 4. 原子化更新状态并发放奖励 const result = await landService.harvest(userId, landIndex); if (!result.success) { return res.status(409).json({ error: '操作冲突，请重试' }); } res.json({ ok: true, reward: result.reward }); });

这段代码里第3步是关键，matureTime是从数据库或Redis里读出来的，不是前端传的。第4步的harvest方法内部要用原子操作，比如UPDATE land SET status = 'empty' WHERE user_id = ? AND land_index = ? AND status = 'mature'，然后检查受影响行数。如果返回0，说明状态已经被其他请求改了，直接返回冲突。

5.2 用日志和埋点验证防作弊是否生效

代码写完之后，怎么知道它真的能防住？我一般会在关键路径上加日志，然后写一个简单的测试脚本模拟异常请求。比如连续调用收获接口10次，看是不是只有第一次成功。或者用两个不同的用户ID去偷同一块地，看是不是只有一个能成功。日志里要记录请求的userId、landIndex、timestamp和result，方便事后排查。如果条件允许，可以在Redis里加一个计数器，记录每个用户每分钟的收获次数，超过阈值就告警。

# 模拟重复收获请求 for i in $(seq 1 10); do curl -s -X POST http://localhost:3000/api/harvest \ -H "Content-Type: application/json" \ -d '{"userId":1,"landIndex":0}' | jq -r '.ok' done # 预期输出：只有第一个true，后面全是false或error

这个测试跑完，如果看到多个true，说明原子操作没生效，需要回去检查数据库更新语句或者Redis脚本。如果全是false，也要确认第一次是不是真的成功了，别把正常请求也拦了。

5.3 一个我常用的习惯：把配置和状态分开验证

最后分享一个我自己的习惯。每次改完农场源码里的配置（比如调整作物成熟时间），我不会直接重启服务了事，而是先写一个小脚本单独验证配置读取和状态计算是否正确。比如：

// verify_config.js const crops = require('./config/crops'); const now = Date.now(); const plantTime = now; const crop = crops['101']; // 胡萝卜 const matureTime = plantTime + crop.growTime * 1000; console.log('作物:', crop.name); console.log('种植时间:', new Date(plantTime).toISOString()); console.log('成熟时间:', new Date(matureTime).toISOString()); console.log('生长时长(秒):', crop.growTime); console.log('预期成熟时间差(毫秒):', matureTime - plantTime);

跑一下这个脚本，确认输出的时间差和配置里的growTime一致，再启动服务。这个习惯帮我省了很多次“改完配置忘了乘1000”的后悔药。农场源码看起来简单，但时间、状态、并发这三件事凑在一起，稍不注意就会翻车。希望这些经验能帮到你。

本文还有配套的精品资源，点击获取