Currently the "no expiration" value is considered to be 0.
TTL api seems bugish to me because it can return 0 even if key has an expiration, thus, a key that expires becomes a key that does not expire on logic level.
Example of applicability:
I have 2 caches, and I want to copy keys from cache1 to cache2, I would use an iterator over cache1, I will have to call TTL api for each entry (currently the Iterator's result does not include this info, only the key and its value) and set the (key,value,ttl) to cache2.
If TTL call for a key would happen in the "wrong" moment (exactly in the second it expires), that key would end up being saved in cache2 "forever".

if hdr.expireAt == 0 {
	timeLeft = 0
	return
} else if hdr.expireAt != 0 && hdr.expireAt >= now { //   ">" instead of ">=" would be more convenient.
	timeLeft = hdr.expireAt - now
	return
}

The line I'm talking about is this one.
This line from evacuate method is similar, there may be also other places, I haven't looked for all of them.

But, here and here for example, you consider a key as "expired" if the difference between current time and expire time would result in 0.

Proposed resolution is to make logic consistent, and consider in all places a key that can expire as

• expired, if key's expiration is <= now
• not expired, if key's expiration is > now