Fix Go "Imported and Not Used" Compilation Errors (2026)

Go’s compiler is strict: unused imports are a compilation error because they indicate potential bugs or dead code.

Here’s how to fix "imported and not used" errors:

1. Explicitly Use the Imported Package

The most straightforward fix is to use something from the imported package. Even a simple function call or accessing a constant is enough.

Diagnosis: Look at the compiler error message. It will tell you which package is unused.
Fix: Add a line of code that uses an exported identifier from that package. For example, if you imported "log" and it’s unused, add log.Println("debug message") somewhere in your function.
Why it works: The compiler sees a symbol from the package being referenced, fulfilling its requirement.

2. Use the Blank Identifier (_) for Side Effects

Sometimes, you import a package solely for its side effects, such as its init() function running code when the package is imported (common for database drivers or logging setup). In Go, you can use the blank identifier (_) to import a package without needing to explicitly use its exported identifiers.

Diagnosis: The error points to a package whose only purpose is its init() function.
Fix: Change import "database/sql" to import _ "database/sql".
Why it works: The import _ "package" syntax tells the Go compiler to import the package and execute its init() function, but it also signals that no symbols from that package will be directly used in your code.

3. Remove the Unused Import

If the package is genuinely not needed, the cleanest solution is to remove the import statement entirely.

Diagnosis: You added an import statement speculatively or during refactoring and forgot to remove it.
Fix: Delete the import "package/name" line from your import block.
Why it works: The compiler is satisfied because the unused import is no longer present.

4. Use a Linter to Identify and Fix (Automated)

Linters like goimports or golangci-lint can automatically clean up unused imports. goimports is particularly popular as it also sorts imports.

Diagnosis: You have multiple unused imports and want a quick, consistent fix.
Fix: Run goimports -w your_file.go or golangci-lint --fix ./... in your project directory.
Why it works: These tools are programmed to detect unused imports and either remove them or apply the blank identifier pattern where appropriate, formatting your code according to Go conventions.

5. Use an Alias for a Package (Less Common Fix for This Specific Error)

While not a direct fix for "unused," sometimes you might have a package imported multiple times with different aliases, and one of those aliases becomes unused. You’d then address it like any other unused import. More commonly, you might use an alias to disambiguate packages with the same name from different modules.

Diagnosis: You have import alias "some/package" and alias is not used.
Fix: Either use alias or remove the import statement and the alias.
Why it works: If the alias isn’t referenced, the compiler flags it as unused. Using it or removing the import resolves the error.

6. Address init Functions That Don’t Register (More Nuanced)

If you’re importing a package solely for its init function, but that init function itself relies on some external registration or configuration that isn’t happening, the import might appear unused or the init might not be doing what you expect. This isn’t strictly an "unused import" error, but it can be a related logical bug.

Diagnosis: You’ve used import _ "package" and the functionality it’s supposed to enable isn’t working. The compiler won’t complain about the import itself being unused in this case, but the effect of the import is missing.
Fix: Ensure that any prerequisite setup for the imported package’s init function is completed before the import is processed (which is usually handled by the Go build tool placing init calls in dependency order). For example, if a database driver’s init function expects sql.Open to have been called with its specific driver name, make sure sql.Open is called correctly.
Why it works: The init function executes implicitly, but its effectiveness depends on its internal logic and external context. Ensuring that context is met allows the init function to perform its intended setup.

The next error you’ll likely encounter after cleaning up unused imports is a "declared and not used" error for a variable, which follows the same underlying principle of Go’s strictness about code correctness.