按地点搜 X：什么还能用，什么已经悄悄坏掉了
按地点搜 X：什么还能用，什么已经悄悄坏掉了
大多数搜这个的人，想要的是一个几乎已经不存在的东西。
心智模型是合理的： 帖子有位置，所以你应该能要到某个地方附近的帖子。★这在 2012 年前后确实好用。★ 今天这个功能技术上还活着，实际上很稀薄，而搞清楚原因能让你不在它上面盖东西。
★一句话版本：地理标记是选择性加入的，几乎没人加入，而按地点搜索只能找到被标记过的那些。★
按地点搜索为什么返回得这么少
给帖子附加位置一直都是可选的，而愿意这么做的用户比例已经下滑了十年。精确地理标记多年前就被淡化，这个设置现在默认关闭。
后果是一道算术题： 如果只有一小部分帖子带坐标，那么一个位置查询搜索的就只是那一小部分。⚠️ ★★你看到的不是"这座城市的帖子"，而是"这座城市里、作者特意标记过的那一小撮少数派帖子"。★★
这两者的差别大到足以推翻大多数「以为自己在看前者、其实在看后者」时得出的结论。
下面所有做法都只用公开数据 —— 我们的接口也在同一条边界内。
仍然有效的位置运算符
X 的搜索语法接受地理运算符，而且是直接透传的：
| 运算符 | 含义 |
|---|---|
near:"London" |
标记在某个地名附近的帖子 |
within:10km |
半径，与 near: 搭配使用 |
geocode:51.5,-0.12,10km |
纬度、经度、半径 |
place:<place_id> |
一个具体的 X 地点标识符 |
import requests
BASE = "https://api.socialapi.tech"
KEY = "your_api_key"
HDRS = {"X-API-Key": KEY}
def near(term, place, radius="25km", limit=50):
"""只覆盖带地理标记的帖子 —— 结果稀薄是设计使然。"""
r = requests.get(f"{BASE}/v1/search/advanced",
params={"query": f'{term} near:"{place}" within:{radius}',
"limit": limit, "product": "Latest"},
headers=HDRS, timeout=60)
r.raise_for_status()
return r.json()["data"]
hits = near("power outage", "Manchester")
print(f"{len(hits)} 条带地理标记的结果")
★把"结果很少"当作预期结果，而不是 bug。★(查询就是搜索语法本身，所以 X 支持什么，这里就支持什么。)如果什么都没返回，通常原因是没人做地理标记，而不是查询写错了。
那个真正有效的位置信号
这是这个话题下大多数文章漏掉的部分： 平台上确实存在一个可靠、数据密集的位置信号，而它不是带地理标记的帖子。
★★热榜是按地区计算的，而喂给它的每一条帖子都被计入 —— 无论作者有没有标记位置。★★
def local_trends(woeid):
"""地区热榜 —— 真正密集的位置数据。"""
r = requests.get(f"{BASE}/v1/trends/place",
params={"woeid": woeid}, headers=HDRS, timeout=60)
r.raise_for_status()
return r.json()["data"]["trends"]
def regions():
"""完整的 WOEID 地区字典。"""
r = requests.get(f"{BASE}/v1/trends/locations", headers=HDRS, timeout=60)
r.raise_for_status()
return r.json()["data"]
for t in local_trends(44418)[:10]: # 44418 = 伦敦
print(f" {t['name']}")
为什么它是更好的工具： 热榜的归属是根据用户在哪里推断出来的，★所以它反映的是整个地区，而不是那一小撮做标记的人★。对于"这座城市现在正在发生什么"这个问题，它回答的正是地理标记搜索只是看起来在回答的那个问题。
地区列表覆盖数百个地方 —— 国家和主要城市，每个都有一个数字 WOEID，传给热榜调用即可。
查一个账号在哪里
另一个落到同一批搜索词上的问题： 不是"某地的帖子"，而是**"这个账号是哪里的"**。
资料页带一个自由文本的位置字段，而这个字段的可靠程度恰如"自由文本"所暗示的 —— 人们会写真实城市、写玩笑、写虚构地点，或者留空。
def stated_location(username):
r = requests.get(f"{BASE}/v1/user/info",
params={"username": username}, headers=HDRS, timeout=60)
r.raise_for_status()
d = r.json()["data"]
return d.get("location") or None # ★自称的,未经校验★
⚠️ ★这是一个声明，不是一次测量。★ 没有任何东西去核实它，而把它当成事实真相，是受众地域分析里最常见的错误。★把它当作跨很多账号时的弱信号，永远不要当作关于某一个账号的事实。★
大家会问的问题
怎么按地点搜推特？
在查询里用 near:"城市" 配合 within:10km。只有带地理标记的帖子会命中。
按地点搜索为什么结果这么少？ ★因为地理标记是选择性加入的，而且很少被使用。★ 功能是好的，数据是稀薄的。
能看到我附近的推文吗？ 只能看到明确标记在你附近的那些。 大多数本地帖子根本不带位置。
怎么查一条推文的位置？ 作者标记了，帖子就带地点数据。否则它根本不存在。
能从某人的推文推断他的位置吗？ 不可靠。 ★没有地理标记才是常态，而资料页位置是自称的。★
怎么给我的推文加位置？ 那是 App 里的发布选项。 ★我们是只读的，不能替你发帖或打标记。★
怎么查一个账号的位置？ 读资料页的位置字段，★但要记得它是未经验证的自由文本★。
资料页的位置准确吗？ 经常不准。 人们会写玩笑、写大区，或者什么都不写。
WOEID 是什么？ 热榜端点使用的地区数字标识符。 地区列表调用会返回完整字典。
怎么拿某个城市的热榜？ 把那个城市的 WOEID 传给按地区取热榜的调用。
有多少地方有热榜？ 数百个 —— 国家加主要城市。不是每座城市都有自己的条目。
看本地动态，热榜比地理标记搜索更好吗？ ★通常是的★，因为热榜包含该地区用户的帖子，不论有没有标记。
能按坐标搜索吗？
能，用 geocode:纬度,经度,半径。同样受地理标记的限制。
半径该设多大？ 比你感觉的更宽。 在本就稀疏的数据上设一个很紧的半径，会什么都搜不到。
near: 对任何城市名都有效吗？
对 X 能识别的地名有效。生僻地名可能解析不出来。
能把位置和日期区间组合吗？ 能 —— 位置运算符可以和日期过滤组合。
能把位置和关键词组合吗？ 能，而且通常应该这么做。单用位置太宽泛，没有用处。
地理标记为什么衰落了？ 隐私。 精确位置分享被淡化，现在默认关闭。
大多数帖子有坐标吗？ 没有 —— ★带标记的比例小到你应该默认任何一条帖子都没有★。
能按地点拿历史帖子吗？ 只能拿被标记的那个子集，而且存档深度限制同样适用。
有没有一个接口能返回某座城市里的所有人？ 没有。★那需要每个用户都有位置，而这并不存在。★
能实时监控一个地点吗？ 你可以监控关键词并读地区热榜 —— 监控怎么做。
怎么找本地新闻账号？ 按城市名搜资料页。做这件事比地理标记搜索有效得多。
位置字段会影响用户看到什么吗？ 他的热榜受地区影响，但资料页那个文本字段本身就只是文本。
能按国家过滤搜索结果吗？ 不能直接过滤。 语言过滤和地区热榜是实际可用的替代。
Twitter Lists 是什么，能搜索吗？ 列表是用户自己整理的账号集合。 你可以按列表 ID 读它的时间线、成员和订阅者 —— 但没有全局的列表搜索。
怎么拿一个列表里的帖子？ 把列表 ID 传给列表时间线调用。★一个列表往往比任何位置查询都更像一个好用的本地信息流，因为它是人工整理的。★
能看到哪些列表收录了某个账号吗？ 列表成员是公开的，不过发现是按列表进行的，不是按成员。
我的位置搜索为什么是空的？ 几乎总是因为没有带地理标记的匹配。 先把半径放宽、把生僻关键词去掉。
位置数据有精确的时候吗？ 被标记时可以很精确。但样本是自选的，而且很小。
能画出一个话题标签在哪里被使用吗？ 只能基于带地理标记的帖子，★这让画出来的图变成一张"谁在做标记"的图★ —— 标签测量的完整口径。
简短版
按地点搜索能用，而如果你期待覆盖度，它会让你失望。 地理标记是选择性加入的、使用率很低，★而一个位置查询永远只能返回做标记的那一小撮少数派★。
真正有效的信号是地区热榜，因为它的归属是推断出来的而不是自愿提供的 —— 它反映整个地区，而不是少数做了标记的人。
我们的 API 把位置运算符直接透传给搜索、按 WOEID 返回分地区热榜并提供完整地区字典、还能按 ID 读列表时间线 —— 所以一个本地信息流可以用热榜加人工整理的列表搭出来，而不是靠稀疏的地理标记。只读、固定按次价格。
没有任何接口能给你什么： 一条从未被标记过的帖子的位置，或者一个账号经过验证的位置。★两者都需要平台并不收集的数据。★
延伸阅读：地区热榜到底在衡量什么 · 完整的搜索运算符 · 按名字或简介找账号 · 持续监控一个话题。