If you take a look at the File struct it has a Read() and Write() function that is exactly the same as io.Writer and io.Reader interface Read() and Write() functions. But the package io is no where to be found in File package (not imported). Does this mean that interfaces do not at all have to be imported to be used? As long as the Read() definition is the same as the interface it can then be implied that it is part of the io.Writer or io.Reader interface?
Package os does not import package io as the io.Reader interface is not used in package os.
The type *File happens to implement io.Reader because it has a Readmethod with the right signature. This implements relation is implicit and it is neither needed nor possible to make this explicite (e.g. like in Java with implements ISomeThing).
You asked: "Does this mean that interfaces do not at all have to be imported to be used?" and the formal answer is: Of course not! If you want to use io.Reader you have to import "io".
But implementing/satisfying an interface is not an use of this interface: Any type implements any interface (even future ones which have not been invented jet) just by having the right methods.
Exported entities are constants, variables and types. To use them, ie. to refer to such exported entities, one has to use their [qualified] name, while the qualifier is the basename of the package which exports them. That also implies using an import statement of such package. IOW, binding exported entities in a file scope is [strictly] explicit. No import == no access to exported stuff.
OTOH, implementing an interface is specified to be implicit:
A type implements any interface comprising any subset of its methods and may therefore implement several distinct interfaces. For instance, all types implement the empty interface:
interface{}