Ethereum adopted Keccak before NIST finalized SHA-3. FIPS 202 then appended domain-separation bits to the message padding (the first padding byte is 0x06 in SHA3-256 and 0x01 in Keccak-256), so the two functions share the permutation and parameters but produce unrelated digests. Keccak-256 of the empty string is c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470, while SHA3-256 of the same input is a7ffc6f8…f8434a.
Ethereum uses it for addresses (the last 20 bytes of the hash of a 64-byte public key), ABI function selectors (the first 4 bytes of the hash of transfer(address,uint256) are a9059cbb), event topics, storage slots, EIP-191 and EIP-712 signing hashes and ecrecover inputs. Solidity's keccak256 and the web3_sha3 RPC method both compute Keccak-256 despite the latter's name.
The classic bug is calling a library's sha3_256 (FIPS) when Ethereum expects Keccak-256: every digest, address and signature check comes out wrong without any error. Use functions named keccak256 or keccak_256.