本文介绍面向地理区域的 json 数据建模方法，重点解决“一个地区对应多个风电场”场景下的结构设计与 javascript 访问问题，提供可扩展、易读、易维护的嵌套数组与对象两种方案。
在构建基于邮编查询本地风电场的工具时，核心挑战在于：同一行政区域（如 "Derbyshire Dales"）可能包含多个独立风电场，而传统键值对式 JSON（如 "Copeland": {"hasWindfarm": "Yes"}）无法表达一对多关系。为兼顾数据可读性、API 兼容性及前端查询效率，推荐以下两种主流组织方式：
✅ 方案一：区域为键，风电场列表为数组（推荐初学者 & 大多数场景）
该结构清晰、扁平、易于遍历，且天然支持动态增删风电场：
{
"Copeland": {
"windfarms": ["Sustainable Keswick"]
},
"Crewe and Nantwich": {
"windfarms": ["Nantwich Hydro"]
},
"Derbyshire Dales": {
"windfarms": [
"Matlock Community Energy Project",
"Derby Dales Community Energy"
]
}
}✅ JavaScript 查询示例（安全访问）：
// 假设已通过 fetch 获取并解析 JSON
const data = await response.json(); // 或 JSON.parse(rawString)
function getWindfarmsByLocation(location) {
if (data[location] && Array.isArray(data[location].windfarms)) {
return data[location].windfarms;
}
return []; // 安全兜底：返回空数组而非报错
}
// 使用示例
const windfarms = getWindfarmsByLocation("Derbyshire Dales");
console.log(windfarms);
// → ["Matlock Community Energy Project", "Derby Dales Community Energy"]⚠️ 注意事项： 务必检查 data[location] 和 windfarms 是否存在，避免 Cannot read property 'length' of undefined 错误； 若需展示更多字段（如地址、装机容量），可将数组元素升级为对象（见方案二）。
✅ 方案二：区域为键，风电场为嵌套对象（适合需丰富元数据的场景）
当每个风电场需携带多维属性（如坐标、建成年份、运营商、发电量）时，使用对象字面量更语义化：
{
"Derbyshire Dales": {
"Matlock Community Energy Project": {
"capacity_mw": 4.2,
"year_commissioned": 2018,
"operator": "Matlock Energy Co-op"
},
"Derby Dales Community Energy": {
"capacity_mw": 6.8,
"year_commissioned": 2021,
"operator": "Dales Renewables Ltd"
}
}
}✅ JavaScript 访问示例：
function getWindfarmDetails(location, farmName) {
const locData = data[location];
if (!locData || typeof locData !== 'object') return null;
return locData[farmName] || null;
}
// 查询具体风电场详情
const details = getWindfarmDetails("Derbyshire Dales", "Matlock Community Energy Project");
console.log(details.capacity_mw); // → 4.2? 进阶建议：
- 若风电场数量庞大或需全文搜索，建议后端提供 /api/windfarms?postcode=SK17 接口，前端仅传参，避免加载冗余 JSON；
- 前端可预处理数据：用 Object.entries() 将 JSON 转为 [["Copeland", {...}], ...] 数组，便于按名称模糊匹配；
- 为提升可维护性，JSON 文件中应添加注释说明字段含义（虽标准 JSON 不支持，但可用 .jsonc 格式或配套 README）。
无论选择哪种结构，保持键名一致性（如统一用 windfarms 而非混用 farms/projects）和层级简洁性，是长期可维护的关键。
