后端【免费下载链接】instagram-private-apiNodeJS Instagram private API SDK. Written in TypeScript.项目地址https://gitcode.com/gh_mirrors/in/instagram-private-api点击查看免费下载LikedFeedResponseLocation 是 instagram-private-api 中用于描述「点赞动态流Liked Feed中单条帖子地理位置」的 TypeScript 接口它承载了帖子打卡地点的名称、经纬度、地址与 Facebook Places 关联信息。本文将逐一拆解该接口的 9 个字段及其类型约束结合点赞流LikedFeed的拉取链路、同构响应家族与发布侧位置映射实现帮助你准确解析、判空并复用 Instagram 的位置数据。接口定位它出现在哪里该接口定义于 src/responses/liked.feed.response.ts是 instagram-private-api 响应模型体系中的一员对应 Instagram 私信接口/api/v1/feed/liked/返回的帖子 JSON 中location对象的类型。从源码结构看LikedFeedResponseLocation并非孤立存在而是嵌套在LikedFeedResponseItemsItem之中并以可选字段形式出现// src/responses/liked.feed.response.ts:40-42 location?: LikedFeedResponseLocation; // 仅当帖子带定位时存在 lat?: number; // 顶层冗余的纬度 lng?: number; // 顶层冗余的经度也就是说点赞流中的每条帖子ItemsItem可能带定位、也可能不带带定位时既可通过结构化的location对象读取完整地点信息也可通过顶层的lat/lng直接读取坐标。点赞流的底层请求由 LikedFeed 发起分页参数为max_id响应体为LikedFeedResponseRootObject而LikedFeed实例则通过 feed.factory.ts 中的ig.feed.liked()创建。字段全览9 个属性的类型与含义属性名类型行号含义说明pknumberL108地点唯一 IDInstagram Location IDnamestringL109地点展示名称如「故宫博物院」addressstringL110详细街道地址citystringL111所属城市short_namestringL112地点的短名称/别名lngnumberL113经度LongitudelatnumberL114纬度Latitudeexternal_sourcestringL115地点数据来源常见如facebook_placesfacebook_places_idnumberL116对应的 Facebook Places ID用于跨平台地点关联其中lat、lng是数字类型的浮点坐标可直接用于地图标注或距离计算external_source与facebook_places_id配合使用是 Instagram 地点体系与 Facebook Places 打通的关键标识。同构响应家族一致的 Location 形状LikedFeedResponseLocation的字段结构在仓库中并非唯一。Instagram 私信接口在多处返回几乎相同的地点对象仓库在以下响应文件中也定义了同构结构src/responses/fbsearch.repository.places.response.tsFbsearchRepositoryPlacesResponseLocation字段逐一对应src/responses/fbsearch.repository.topsearch-flat.response.tstopsearch 混排结果中的Placesrc/responses/location.repository.info.response.ts地点详情接口返回src/responses/list-reel-media-viewer.feed.response.ts故事浏览量列表中的地点信息。一个实用推论是只要某个响应体中出现pk / name / address / city / short_name / lng / lat / external_source / facebook_places_id这一组字段即可按LikedFeedResponseLocation的结构去解析这为编写通用位置解析工具提供了便利。实战一读取点赞流中的位置信息获取「我赞过的帖子」并提取地点最直接的方式是遍历LikedFeedimport { IgApiClient } from instagram-private-api; const ig new IgApiClient(); ig.state.generateDevice(your-username); await ig.account.login(your-username, your-password); const likedFeed ig.feed.liked(); // 创建点赞流 Feed const items await likedFeed.items(); // 拉取当前页帖子 for (const item of items) { if (item.location) { const loc item.location; console.log({ id: loc.pk, name: loc.name, city: loc.city, coords: [loc.lat, loc.lng], source: loc.external_source, facebookPlacesId: loc.facebook_places_id, }); } else { // 无结构化 location 时可回退到顶层 lat/lng可选字段 console.log(fallback coords: ${item.lat}, ${item.lng}); } } // 分页继续拉取下一页 while (likedFeed.isMoreAvailable()) { const next await likedFeed.items(); // 处理 next... }要点说明location与顶层lat/lng均为可选字段读取前务必判空源码位于 liked.feed.response.ts分页由 LikedFeed.request() 内部维护max_id外部只需循环调用items()并检查isMoreAvailable()pk可作为后续调用地点详情接口的入参见下文。实战二从地点 ID 回溯完整地点信息拿到location.pk后可通过LocationRepository进一步查询该地点的详情与故事聚合ig.locationSearch.info(id)→ 请求/api/v1/locations/${id}/info/返回LocationRepositoryInfoResponseRootObject其中同样包含lng / lat / external_source / facebook_places_id等字段见 src/repositories/location.repository.tsig.locationSearch.story(id)→ 请求/api/v1/locations/${id}/story/获取该地点的故事内容location.repository.ts。const loc item.location; if (loc) { const info await ig.locationSearch.info(loc.pk); // 地点详情 const story await ig.locationSearch.story(loc.pk); // 地点故事 }实战三响应字段到发布表单的反向映射LikedFeedResponseLocation不仅用于读取其字段语义还与发布侧位置提交完全对应。仓库在 src/services/publish.service.ts 中定义了makeLocationOptions将发布参数PostingLocation见 src/types/posting.options.ts映射为上传表单// PostingLocation发布入参 interface PostingLocation { name: string; lat: number; lng: number; external_id_source: string; // 对应响应中的 external_source external_id: string; address: string; }映射逻辑要点publish.service.tsexternal_id_source→ 表单中的location.external_source额外生成${external_id_source}_id字段如facebook_places_id同时写入geotag_enabled 1、media_latitude、media_longitude、posting_latitude、posting_longitude。这解释了为何响应结构中既有external_source又有facebook_places_id二者正是发布时地理标签geotag所必需的来源标识与外部 ID。仓库示例 examples/upload-photo.example.ts 展示了完整的「搜索地点 → 选择 venue → 随照片发布」流程其中ig.search.location(latitude, longitude, searchQuery)返回的 venue 可直接作为publish.photo的location入参。配套的地点查询接口若想在自己的应用里先搜地点再写入发布参数仓库提供了两条路径ig.search.places(query)→ 内部调用fbsearch.places请求/api/v1/fbsearch/places/返回的items[].location形状与LikedFeedResponseLocation完全一致src/repositories/fbsearch.repository.tsig.search.location(latitude, longitude, query?)→ 内部调用locationSearch.index返回 venues 列表包含external_id、external_id_source、lat、lng、address等字段src/services/search.service.ts 与 src/responses/location.repository.search.response.ts。小结LikedFeedResponseLocation是理解 Instagram 地点数据在 instagram-private-api 中如何「读取、解析、复用、回写」的钥匙结构9 个字段覆盖 ID、名称、地址、城市、短名、经纬度、来源与 Facebook Places 关联定位作为LikedFeedResponseItemsItem.location的可选子对象需判空后使用通用性同构结构遍布 places 搜索、topsearch、地点详情与故事浏览等响应可统一解析闭环其字段语义与发布侧PostingLocation/makeLocationOptions一一对应支持「查询地点 → 读取帖子位置 → 发布带定位内容」的完整链路。相关源码索引响应定义、点赞流 Feed、Feed 工厂、发布位置映射、地点仓库、上传示例。赞分享后端【免费下载链接】instagram-private-apiNodeJS Instagram private API SDK. Written in TypeScript.项目地址https://gitcode.com/gh_mirrors/in/instagram-private-api点击查看免费下载相关推荐使用 ChatPaper 阅读论文从命令行、Flask Web 到 Docker 与 Hugging Face 的完整部署指南使用 ChatPaper 阅读论文从命令行、Flask Web 到 Docker 与 Hugging Face 的完整部署指南 ChatPaper 是一个利用后端instagram-private-api 响应类型解析HighlightsRepositoryEditReelResponseCover_media 高亮封面数据结构详解instagram private api 响应类型解析HighlightsRepositoryEditReelResponseCover_media 高亮封后端instagram-private-api 响应类型解读ListReelMediaViewerFeedResponseHashtag 结构与实战应用instagram private api 响应类型解读ListReelMediaViewerFeedResponseHashtag 结构与实战应用 导读 L后端上一篇零配置Docker测试革命JUnit与gh_mirrors/do/dockerfiles的无缝集成方案下一篇VirtualSMC故障排除手册10个常见问题及解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/16 1:55:20 · 阅读 1.2k instagram-private-api 响应类型详解：LikedFeedResponseLocation 位置数据结构与实战解析
后端【免费下载链接】instagram-private-apiNodeJS Instagram private API SDK. Written in TypeScript.项目地址https://gitcode.com/gh_mirrors/in/instagram-private-api点击查看免费下载LikedFeedResponseLocation 是 instagram-private-api 中用于描述「点赞动态流Liked Feed中单条帖子地理位置」的 TypeScript 接口它承载了帖子打卡地点的名称、经纬度、地址与 Facebook Places 关联信息。本文将逐一拆解该接口的 9 个字段及其类型约束结合点赞流LikedFeed的拉取链路、同构响应家族与发布侧位置映射实现帮助你准确解析、判空并复用 Instagram 的位置数据。接口定位它出现在哪里该接口定义于 src/responses/liked.feed.response.ts是 instagram-private-api 响应模型体系中的一员对应 Instagram 私信接口/api/v1/feed/liked/返回的帖子 JSON 中location对象的类型。从源码结构看LikedFeedResponseLocation并非孤立存在而是嵌套在LikedFeedResponseItemsItem之中并以可选字段形式出现// src/responses/liked.feed.response.ts:40-42 location?: LikedFeedResponseLocation; // 仅当帖子带定位时存在 lat?: number; // 顶层冗余的纬度 lng?: number; // 顶层冗余的经度也就是说点赞流中的每条帖子ItemsItem可能带定位、也可能不带带定位时既可通过结构化的location对象读取完整地点信息也可通过顶层的lat/lng直接读取坐标。点赞流的底层请求由 LikedFeed 发起分页参数为max_id响应体为LikedFeedResponseRootObject而LikedFeed实例则通过 feed.factory.ts 中的ig.feed.liked()创建。字段全览9 个属性的类型与含义属性名类型行号含义说明pknumberL108地点唯一 IDInstagram Location IDnamestringL109地点展示名称如「故宫博物院」addressstringL110详细街道地址citystringL111所属城市short_namestringL112地点的短名称/别名lngnumberL113经度LongitudelatnumberL114纬度Latitudeexternal_sourcestringL115地点数据来源常见如facebook_placesfacebook_places_idnumberL116对应的 Facebook Places ID用于跨平台地点关联其中lat、lng是数字类型的浮点坐标可直接用于地图标注或距离计算external_source与facebook_places_id配合使用是 Instagram 地点体系与 Facebook Places 打通的关键标识。同构响应家族一致的 Location 形状LikedFeedResponseLocation的字段结构在仓库中并非唯一。Instagram 私信接口在多处返回几乎相同的地点对象仓库在以下响应文件中也定义了同构结构src/responses/fbsearch.repository.places.response.tsFbsearchRepositoryPlacesResponseLocation字段逐一对应src/responses/fbsearch.repository.topsearch-flat.response.tstopsearch 混排结果中的Placesrc/responses/location.repository.info.response.ts地点详情接口返回src/responses/list-reel-media-viewer.feed.response.ts故事浏览量列表中的地点信息。一个实用推论是只要某个响应体中出现pk / name / address / city / short_name / lng / lat / external_source / facebook_places_id这一组字段即可按LikedFeedResponseLocation的结构去解析这为编写通用位置解析工具提供了便利。实战一读取点赞流中的位置信息获取「我赞过的帖子」并提取地点最直接的方式是遍历LikedFeedimport { IgApiClient } from instagram-private-api; const ig new IgApiClient(); ig.state.generateDevice(your-username); await ig.account.login(your-username, your-password); const likedFeed ig.feed.liked(); // 创建点赞流 Feed const items await likedFeed.items(); // 拉取当前页帖子 for (const item of items) { if (item.location) { const loc item.location; console.log({ id: loc.pk, name: loc.name, city: loc.city, coords: [loc.lat, loc.lng], source: loc.external_source, facebookPlacesId: loc.facebook_places_id, }); } else { // 无结构化 location 时可回退到顶层 lat/lng可选字段 console.log(fallback coords: ${item.lat}, ${item.lng}); } } // 分页继续拉取下一页 while (likedFeed.isMoreAvailable()) { const next await likedFeed.items(); // 处理 next... }要点说明location与顶层lat/lng均为可选字段读取前务必判空源码位于 liked.feed.response.ts分页由 LikedFeed.request() 内部维护max_id外部只需循环调用items()并检查isMoreAvailable()pk可作为后续调用地点详情接口的入参见下文。实战二从地点 ID 回溯完整地点信息拿到location.pk后可通过LocationRepository进一步查询该地点的详情与故事聚合ig.locationSearch.info(id)→ 请求/api/v1/locations/${id}/info/返回LocationRepositoryInfoResponseRootObject其中同样包含lng / lat / external_source / facebook_places_id等字段见 src/repositories/location.repository.tsig.locationSearch.story(id)→ 请求/api/v1/locations/${id}/story/获取该地点的故事内容location.repository.ts。const loc item.location; if (loc) { const info await ig.locationSearch.info(loc.pk); // 地点详情 const story await ig.locationSearch.story(loc.pk); // 地点故事 }实战三响应字段到发布表单的反向映射LikedFeedResponseLocation不仅用于读取其字段语义还与发布侧位置提交完全对应。仓库在 src/services/publish.service.ts 中定义了makeLocationOptions将发布参数PostingLocation见 src/types/posting.options.ts映射为上传表单// PostingLocation发布入参 interface PostingLocation { name: string; lat: number; lng: number; external_id_source: string; // 对应响应中的 external_source external_id: string; address: string; }映射逻辑要点publish.service.tsexternal_id_source→ 表单中的location.external_source额外生成${external_id_source}_id字段如facebook_places_id同时写入geotag_enabled 1、media_latitude、media_longitude、posting_latitude、posting_longitude。这解释了为何响应结构中既有external_source又有facebook_places_id二者正是发布时地理标签geotag所必需的来源标识与外部 ID。仓库示例 examples/upload-photo.example.ts 展示了完整的「搜索地点 → 选择 venue → 随照片发布」流程其中ig.search.location(latitude, longitude, searchQuery)返回的 venue 可直接作为publish.photo的location入参。配套的地点查询接口若想在自己的应用里先搜地点再写入发布参数仓库提供了两条路径ig.search.places(query)→ 内部调用fbsearch.places请求/api/v1/fbsearch/places/返回的items[].location形状与LikedFeedResponseLocation完全一致src/repositories/fbsearch.repository.tsig.search.location(latitude, longitude, query?)→ 内部调用locationSearch.index返回 venues 列表包含external_id、external_id_source、lat、lng、address等字段src/services/search.service.ts 与 src/responses/location.repository.search.response.ts。小结LikedFeedResponseLocation是理解 Instagram 地点数据在 instagram-private-api 中如何「读取、解析、复用、回写」的钥匙结构9 个字段覆盖 ID、名称、地址、城市、短名、经纬度、来源与 Facebook Places 关联定位作为LikedFeedResponseItemsItem.location的可选子对象需判空后使用通用性同构结构遍布 places 搜索、topsearch、地点详情与故事浏览等响应可统一解析闭环其字段语义与发布侧PostingLocation/makeLocationOptions一一对应支持「查询地点 → 读取帖子位置 → 发布带定位内容」的完整链路。相关源码索引响应定义、点赞流 Feed、Feed 工厂、发布位置映射、地点仓库、上传示例。赞分享后端【免费下载链接】instagram-private-apiNodeJS Instagram private API SDK. Written in TypeScript.项目地址https://gitcode.com/gh_mirrors/in/instagram-private-api点击查看免费下载相关推荐使用 ChatPaper 阅读论文从命令行、Flask Web 到 Docker 与 Hugging Face 的完整部署指南使用 ChatPaper 阅读论文从命令行、Flask Web 到 Docker 与 Hugging Face 的完整部署指南 ChatPaper 是一个利用后端instagram-private-api 响应类型解析HighlightsRepositoryEditReelResponseCover_media 高亮封面数据结构详解instagram private api 响应类型解析HighlightsRepositoryEditReelResponseCover_media 高亮封后端instagram-private-api 响应类型解读ListReelMediaViewerFeedResponseHashtag 结构与实战应用instagram private api 响应类型解读ListReelMediaViewerFeedResponseHashtag 结构与实战应用 导读 L后端上一篇零配置Docker测试革命JUnit与gh_mirrors/do/dockerfiles的无缝集成方案下一篇VirtualSMC故障排除手册10个常见问题及解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考